Date: Sat, 24 Jan 2004 11:48:13 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Don Bowman <don@sandvine.com> Cc: current@freebsd.org Subject: RE: DragonflyBSD kernel clock improvements Message-ID: <200401241948.i0OJmDpo036688@apollo.backplane.com> References: <FE045D4D9F7AED4CBFF1B3B813C85337035E4680@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
It isn't jitter. It's consistently too long. While it is true
that the spec allows for this, there isn't much of a point in having
a 'nanosleep' call (emphasis on 'nano') which produces wildly
varying results for small intervals. While I haven't completely
solved this issue yet (I have to completely rewrite the timer code
to fix it properly), it has been made far more consistent.
Second, the fractional compensation code for the 8254. The 8254 runs
at 1193182 Hz. If your 'hz' is set to 100, a fixed clock reload value
of 11931 looses significant precision. The higher your 'hz' setting,
the more precision is lost and the greater the error verses real time.
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.
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.
So the fractional compensation code is designed to minimize this error.
The fractional compensation code is NOT the PLL.
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 third part is not really necessary, but it was fun to do so I
did it. I like consistency and I hate sawtooth patterns.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401241948.i0OJmDpo036688>