[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7
david-taylor at blueyonder.co.uk.invalid
Mon Dec 2 17:07:10 UTC 2013
On 02/12/2013 16:24, Brian Inglis wrote:
> When I ran current stable under Win 7 with only network servers I found
> I had to drop minpoll to 4 (default is 6) so iburst would quickly get
> a good offset and pull drift down from initial out-to-lunch estimate
> compared to drift file contents.
> Once drift got pulled down close to hardware levels, poll would increase
> and further pull down offset < 10ms, then at longer poll intervals,
> both drift and offset would slowly get more accurate over a period of
> about three weeks.
> About then patch Tuesday would come around and it would be back to
> square one!
> I had to ensure BIOS spread spectrum and OS power saving were turned off
> and pick servers that were not busy, with no drops or steps, delay < 90ms,
> jitter < 20ms, offset < 10ms.
> As pings were often blocked, I used traceroute (tracert on Windows) to do
> initial delay estimates, when those were not also blocked in a DMZ, and
> tried ntpq -p -c rv -c cv as a final check out when possible.
> I try to pick about four good quality servers which may be quite distant,
> but within the criteria above, and four decent fairly local servers for
> those times when interconnects fail and only local servers are reachable.
> One thing I have noticed is that my NTP clock (HPET) is being reported
> as having ~28PPM drift where my hardware is only ~.9PPM!
.. which all seems a lot of effort compared to getting your own
stratum-1 server with no soldering for around US $150:
More information about the questions