Re: [gpsd-dev] [PATCH] Hal Murray's explanations of how ntpd drift works

[Greg Troxel]

  +While ntpd is adjusting the polling interval, it is assuming that the drift
  +is not changing.  It gets confused if your drift changes abruptly, say
  +because you started some big chunk of work on a machine that's usually idle
  +and that raises the temperature.

There's a combination of phase-locked and frequency-locked loop.  The
use of "assume" and "confused" is unwarranted anthropomorphism and not
helpful.  In cases of sudden frequency shift, I'd expect the phase
error to increase (due to accumulation from unmodeled frequency error),
and that will reduce the polling/loop interval.  That's not confused;
it's just the way the system responds, and it's a reasonable response.


  +If you restart ntpd, it should start with a close old drift value and quickly
  +converge to the newer slightly different value.  If you reboot, expect it to
  +converge to a new/different drift value and that may take a while depending
  +on how different the basic calibration factors are.

The notion that the clock frequency may change every reboot is
Linux-specific and should not appear unqualified.  The issue of how
various operating systems derive system time on various hardware is
quite complicated.

pgpDeNnsgj6EC.pgp
Description: PGP signature