New tour-document section explaining the clock interface and PLL.

[Gary E. Miller]

Yo Eric!

On Wed, 28 Sep 2016 16:32:33 -0400
"Eric S. Raymond" <esr at 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
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160928/dba1bc13/attachment.bin>