[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7

David Taylor 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:

   http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
 
http://ava.upuaut.net/store/index.php?route=product/product&path=59_60&product_id=95

-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list