[ntp:questions] NTP rootdelay and rootdispersion problem

Dave Hart hart at ntp.org
Sat Nov 19 11:58:57 UTC 2011

On Sat, Nov 19, 2011 at 11:06, David Woolley
<david at ex.djwhome.demon.invalid> wrote:
> blji wrote:
>> Why my NTP server is not rejecting this untrusted primary source. It
>> is still in sync with this primary source where delay is more (550ms
>> to 720 ms) (poll interval is 1024s)
> The default maxdistance is 1 second.  720ms delay only contributes 360ms.
> 1024 seconds by 8 polls only contributes 123 ms dispersion.

David Woolley hit the nail on the head here.  You haven't told us the
root dispersion that server is reporting to your NTP server, nor the
dispersion your NTP server reports for its hop to that server.  David
did some calculations to infer likely values and his math says the
dispersion of hop from your server to its source is no more than about
360 + 123 = 483 msec.  Your ntpd will add the server's reported root
dispersion to the dispersion from its connection to the server (483
msec by inference) and only if the sum exceeds 1000 msec (1 second)
will the server be rejected outright (as opposed to outvoted by other

Try running:

ntpq -p yourserver

replacing "yourserver" with the DNS name or IP address of your NTP
server.  Assuming there is just one line in that "peers billboard",
listing the untrusted primary server's name or IP address, next try:

ntpq -c "rv &1"

to see everything your server reports about its association with that
untrusted primary server.  If there are two entries and the one in
question is listed second, use &2 instead of &1.  To focus in on the
numbers that matter here:

ntpq -c "rv &1 rootdisp dispersion"

Add those two numbers together and you get the root distance or root
dispersion of the untrusted primary server as seen by your server.  If
this value is less than 1 second, the failure to reject it is by
design.  You can lower the maximum distance allowed from 1s to force
rejection at a lower threshold, but why would you want to ignore it
when it's your only source?  The alternative is to free run based on
your last frequency correction, causing your NTP server's root
dispersion to increase by 15 msec/sec until the single remote source
is no longer rejected.  If that rejection lasts long enough, any
clients trying to sync to your NTP server will reject it because its
root dispersion will exceed 1 second.

Separately, why are you using one "untrusted primary server" as your
sole source?  That makes it trusted by design.  Why not use 4 or more
untrusted servers (whether primary (s1) or secondary (s2 and up), and
let ntpd compare them against each other to decide which one(s) to
believe?  They should all be reporting the same UTC time, so comparing
multiple untrusted sources' agreement is a way to gain trust from a
chorus of untrusted individual voices.

Dave Hart

More information about the questions mailing list