Re: strange behaviour of ntp peerstats entries.

Guys,

There seems to be widespread misunderstanding about how ntpd ranks the survivors. The sort ranks the survivors first by stratum and then by what the spec calls root distance within the same stratum. Root distance is calculated as one-half the root roundtrip delay plus the root dispersion plus the jitter. This is the maximum error of the client relative to the primary source. Note that jitter usually plays only a small part in the calculation, unless there is some timequake or other dramtic event at the server.

Sometimes oneor more of these quantities changes dramatically due to a timequake or maybe the server has lost all its sources for awhile. So, before you conclude ntpd is doing something evil, check each of the contributions to root distance.

The result of the sort is usually the first entry on the list, but even that can be temporarily displaced by the anti-clockhop algorithm. Other than this wiggle, it can be truthfully said that the algorithm selects the servers at the lowest stratum and from among those at that stratum the candidate with the lowest maximum error.

You may argue this is not your goal; you might want the lowest jitter and disregard all else. Be advised the criteria needs to be stable and not change a lot very fast; otherwise, clockhopping can easily become clockleaping.

Dave

David J Taylor wrote:

Brian Utterback wrote:
[]

Which is why NTP prefers the source with the smallest delay. The
system I am using has servers whose delays are 51ms to 94. I can't
find any closer. On my company LAN, the delays range from 16ms to
87ms. The offsets of all these servers agree to within 9ms. Sure, I
am not going to get sub-millisecond from that, but I think it is probably
more typical than your set-up.

Brian Utterback


Brian,

I know this is supposed to happen, but I recall seeing behaviour some time ago where a server with a little more jitter and much more delay was preferred, almost as if it was the jitter/offset which was the measure rather than offset itself. I ended up adding a "prefer" qualifier.

Cheers,
David


.

Relevant Pages

  • Re: NTPd Server - Windows XP error
    ... > server ntp.cpsc.ucalgary.ca ... > time simple was rejected because: The peer's stratum is less than the ... Your host is not yet synced in the above ntpdc -p output. ...
    (comp.unix.bsd.freebsd.misc)
  • Stuck at stratum 16
    ... I cannot seem to get my server to out of stratum 16. ... Is the offset and jitter in milliseconds? ... server 0.north-america.pool.ntp.org iburst ...
    (comp.protocols.time.ntp)
  • Re: strange behaviour of ntp peerstats entries.
    ... system I am using has servers whose delays are 51ms to 94. ... some time ago where a server with a little more jitter and much more ... Doesn't ntpd choose a peer based on stratum also? ... but IIRC the remote server was at the same or higher ...
    (comp.protocols.time.ntp)
  • Re: Local NTP for 5 Subnets
    ... sorry, stratum 5 was only testing, actually this is set to 10. ... ntpq -p on the server shows: ...
    (comp.protocols.time.ntp)
  • Cannot synchronize to server with local clock
    ... fudged at a high stratum like 8 or 10. ... The *server* stratum varies from 16 ... Without sync machines will diverge. ... and another one stratum 14 on a given client. ...
    (comp.protocols.time.ntp)