"Expensive timeout(9) function..."

[Mike Silbersack]

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