Re: DragonflyBSD kernel clock improvements

In message <200401241948.i0OJmDpo036688_at_apollo.backplane.com>, Matthew Dillon w
rites:
>    There are a couple of things going on here... it isn't all just fluff.
>
>    First, the basic problem is that nanosleep() (aka sleep() aka
>    usleep()) consistently sleeps for far longer then the requested time.

I think this was subject to Brucification last it was raised on our
lists.

>    If you are using the 8254 as your wallclock, then you will see a
>    significant 'speed up' of the wall clock at higher hz settings.

Unless you have replaced timecounters this is not true.  Timecounters
are insensitive to how your Hz ticks, as long as it does it often
enough.  (You should probably pull in the code from -current though,
the 4.x code has some marginal issues).

>    hz will wind up being far higher then the true frequency you
>    requested.  It isn't just jitter... it's a permanent error factor and
>    it can create significant problems if you are running ntpd.

Only if you replaced timecounters.

>    Third, if you are not using the 8254 for your wallclock there will be
>    persistent drift between clocks based on the 8254's hz-based interface
>    (ticks) and clocks based on realtime.  The PLL part of the fix simply
>    compensates for the 8254's constant drift relative to the wallclock
>    by occassionally adding one or subtracting one from the 8254's reload
>    value.

This is harmless but IMO also pointless.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.