[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7
Brian.Inglis at SystematicSw.ab.ca
Tue Dec 3 00:34:48 UTC 2013
On 2013-12-02 10:07, David Taylor wrote:
> 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:
BTDT, but we all still need decent network servers as check and backup in case
there are ref clock issues - we don't all have an in house NTP Server farm! ;^>
Take care. Thanks, Brian Inglis
More information about the questions