[ntp:questions] NTP 128ms
Brian.Inglis at Shaw.ca
Thu Oct 6 18:16:23 UTC 2016
On 2016-10-06 06:49, MORRIS, Joe J wrote:
> Probably a simple answer, but I don't seem to be able to find it. I
> understand that any difference between the time source and expected
> time on the client below 128ms will result in the local time being
> changed to reflect the new time. What safeguards are there in place
> to stop the time source (either through fault or malicious attack)
> changing the time by say 100ms every time its polled? Assuming a poll
> every minute, over 10 minutes, the time could be changed by a
With an offset below the step threshold (default 128ms), system time
will be slewed to discipline it towards UTC; above the step threshold,
system time will be stepped to set it to UTC: this is normally done only
once at startup; if any offset exceeds the panic threshold (default
1000s), ntpd will exit: this may be bypassed once only at startup with
option -g (panicgate); see:
Much of the ntpd code is sanity checking to ensure that bad data is
ignored, and only truechimers are selected to estimate UTC; see:
If the number of sources deemed truechimers are not greater than the
number of sources deemed falsetickers, no majority clique exists, and
the system time adjustment is not changed: see select above Figure 2.
Many default operating parameters may be changed by the configuration
tos statement; see:
N.B. RTFM: "HERE BE DRAGONS!"
For greatest accuracy and consistency, a timing quality GPS with PPS
can be connected to a low latency serial port or other IO connector
on a system running with kernel PPS and NTP API support (most Unix).
With a good sky view this keeps time within us of UTC; use a good
GPSDO (with OCXO) supporting NTP and you can stay within ns of UTC.
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
More information about the questions