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]"