In message <[EMAIL PROTECTED]>, Mike Silbersack writes:

>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.

>Actually, we could improve it quite a bit if someone adds NANODELAY()
>(hint, hint...)  Couldn't we have a first-run nanodelay that just used
>nanotime to do the counting for it?

It should probably be called either nanosleep() or nanospin().

It is not a trivial task to do it.

Writing the short end calibration code to be sufficiently robust
and precise will take some time and a lot of experiments.

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
[EMAIL PROTECTED]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to