Date: Tue, 1 Apr 2003 13:31:30 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: hackers@freebsd.org Subject: Re: "Expensive timeout(9) function..." Message-ID: <20030401132751.I564@odysseus.silby.com> In-Reply-To: <57215.1049219837@critter.freebsd.dk> References: <57215.1049219837@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 1 Apr 2003, Poul-Henning Kamp wrote: > >Yeah, I suppose limiting it to one mii_tick routine per second would help > >somewhat... but it's still a bad situation. > > I wasn't advocating slowing it down that much, merely trying to run it > sequentially out of timeout()'s hair. <shrug> Either way would be fine, I don't think there's any major need for a poll once per second. > There used to be a crumbled note with this somewhere in my stack > of TODO items, but by now I suspect that it is ironed perfectly > flat from the weight of all the stuff on top of it. > > But to add to my knowledge-base: What length of delays are you > looking for ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I'd be happy with 100ns granularity (rounded up), with no major concern for jitter. For the purposes of the MII delays, all we really care is that we wait long enough; if we wait too long sometimes, that's no big deal. For reference, 3Com's documentation states that 40ns should be enough, but our current DELAY on i386 seems to take a few uS last time I checked. So, even if you can only get 300ns granularity, that'd still save a lot of time. This is why I suggested using something which just reads nanotime in a loop; nanotime should be accurate enough, right? BTW, does it appear to everyone else that half of these messages are getting dropped on their way to the lists, or is it just me? Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030401132751.I564>