On 2013-12-05 11:58, David Woolley wrote:
On 05/12/13 14:24, mike cook wrote:
The problem for ntp is that ntp takes a long time to recover from a bad
drift value.
This seems to have been an issue since I started using ntp, more than 10 years
ago. I am surprised that it is not fixed.
If you know the drift file is unreliable, you should delete it.
ntpd will then perform a frequency calibration before entering the main loop.
Otherwise it starts on the basis that the drift value is good and it is seeing
measurement errors.
I have automated the saving and restoring of drift files with good values
to replace drift files with bad values at startup, as the calibration on
Windows is way off, and it's often quicker to restart than wait many hours
ordays.
Possibly because MS disclaims timing within 2 seconds as an unreasonable
goal under Windows, and none of the Windows timing interfaces really are
good enough for NTP.
The hardware could be if it was used properly, but what Windows does with
timers makes them unreliable black boxes.
At least from current stable forwards, drift does converge reliably, whereas
previous releases has drift and offset tracking each other all over the place.
--
Take care. Thanks, Brian Inglis
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
