Yo Eric! On Wed, 28 Sep 2016 16:32:33 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote:
> The slewing variations in clock speed are
> so small that they're generally invisible even to soft-realtime
> applications.
Got a number on this? chronyd can slew the clock up to 8.5% for
extended periods of time.
> The KERNEL_PLL code can produce
> much faster convergence from a cold start.
For currently unknwon reasons.
> You need ballpark of 9
> digits of accuracy on the time/cycle and that has to get carried
> through the calculations.
decimal digits or binary digits?
> On PCs, Linux measures the time/cycle at boot time by comparing with
> another clock with a known frequency.
Really? What other clock? My PC's only have two crystals and the one
in the RTC is always sucky..
> There is another API that says "slew the clock by X seconds". That is
> implemented by tweaking the time/cycle slightly, waiting until the
> correct adjustment has happened, then restoring the correct
> time/cycle. The "slight" is 500 PPM. It takes a long time to make
> major corrections.
Compared to the 8.5% that chronyd uses. Maybe the 500 PPM should
be made bigger?
> There is a PLL kernel option to track a PPS. It's not compiled into
> most Linux kernels.
Sadly the RFC 2783 interface has no way of telling if the PPS signal is
valid. It also lacks the sanity checks that gpsd and ntpd apply to the
PPS before using it. So RFC 2783 is unuseable for directly consuming
PPS from garden variey GPS that have no accurate holdover.
> RFC 1589 covers the above timekeeping and slewing and kernel PLL.
And note that Miles notes the kernel PLLL is uperior to the userspace
PLL:
"The PLL design is identical to the one originally implemented in
NTP and described in [3]. In this design the software daemon
simulates the PLL using the adjtime() system call; however, the
daemon implementation is considerably complicated by the
considerations described above. The modified kernel routines
implement the PLL in the kernel using precision time and frequency
representions, so that these complications are avoided. "
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
pgpn2r6XaYydX.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
