[ntp:questions] 500ppm - is it too small?
David Woolley
david at ex.djwhome.demon.co.uk.invalid
Sat Aug 15 09:37:50 UTC 2009
nemo_outis wrote:
> ...
>> Instead I see what looks like a religion, where questions are treated as
> apostasy or treason.
Sycophancy is common on internet forums.
In this particular case, my view is that any clock that is out by more
than 500ppm has something fundamentally wrong with it that should be
addressed before trying to run time discipline software on it. If the
actual hardware clock is out by this much, there is a good chance that
it is not being effectively disciplined by its crystal and will be very
unstable. If the machine is losing clock interrupts, that needs to be
fixed, avoided (e.g. by using a sustainable clock interrupt frequency),
or compensated for by OS specific code. If the clock frequency
calibration is unreliable, it needs to be fixed (e.g. remember from
startup to startup, use a longer baseline for the calibration, or ensure
that the calibration is done on a quiet system).
As Unruh says, some of the things that need doing to ntpd to improve its
real world performance are so radical, that the result would not be a
conforming implementation of NTP. One of the key issues is that NTP
clients can also be NTP servers, so behaviour difference have network
wide implications.
When using conforming NTP algorithms, I believe that certain parameters
have been set on the basis that nowhere in the trail back to stratum 0
will you find a machine that is slewing at faster than 500ppm
(presumably plus an allowance for a reasonable static clock error). One
could probably keep the standard NTP algorithms and parameters and
permit a faster slew at start up, but one would need to refuse to act as
a peer or server until confidence had been built that one had a good
estimate of the static error. From then on one would have to report the
frequency offset from that value, not from the boot time value provided
by the kernel, i.e one would do ones own once per session frequency
calibration.
As I suspect many people with bad clocks only want leaf node client
operation, in spite of the contra-indication of having a local clock
configured, for many people having a leaf mode only mode which removed
slew rate restrictions might be acceptable. Technically, such
implementations are SNTP, rather than NTP, even if they retain some of
the NTP algorithms.
More information about the questions
mailing list