Le 6 déc. 2013 à 10:53, Harlan Stenn a écrit : > mike cook writes: >>> If you know the drift file is unreliable, you should delete it. ntpd >>> will then perform a frequency calibration before entering the main >>> loop. ... >> >> This is what has been recommended for ages but it doesn't completely >> fix the issue. It still takes a long time to settle. Here are the >> results of a test I did using the same system and ntp config as in my >> previous reply wit h the unrepresentative drift file data. > > An "unrepresentative drift file" is not a "deleted drift file".
All I'm saying here is that the same config was used. > >> So under 5 minutes after the start we have a first estimation of the >> drift. It is not that bad, being only 10ppm from normal. >> >> The drift file is not updated until an hour after startup, as >> before. This is a shame as this better approximation would help if >> there was a restart during this time. > > So you are trying to shave the sync time down from 5 minutes for the > case where somebody reboots the box within an hour of having rebooted > the box? I am not trying to do anything. Just pointing out what I think is non optimal behavior. > >> Fri Dec 6 00:30:49 CET 2013 >> *145.238.203.14 .TS-3. 1 u 31 64 377 14.237 -1.681 0.= >> 254 >> mintc=3D3, offset=3D-1.681362, frequency=3D-33.536, sys_jitter=3D0.253768, >> -rw-r--r-- 1 root root 8 Dec 6 00:30 /var/lib/ntp/ntp.drift >> -33.536 >> >> We don't get back to the normal stable state until around 2hrs after >> restart. > > and by then the drift file will have been written twice, the first time > getting you to within 10ppm and the second time that gets you better > than that, right? > > So this discussion is really about convergence, and apparently in the > situation where folks do things to specifically mess things up just to > see how long it takes to fix them? Just highlighting 2 corner cases relevant to the OP. In their case, IIRC they had issues with cpu stepping which left crappy drift file data hanging around. They were not "messing things up". > > H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions