unruh writes: > On 2013-12-05, mike cook <michael.c...@sfr.fr> wrote: > > > > Le 4 d?c. 2013 ? 22:41, antonio.marchese...@gmail.com a ?crit : > > > >> > >>> > >>>> I kept monitoring the drift file, but it was stable. > >> > >>> Were you monitoring the modification times as well as the contents? As th > e logs were not being updated, maybe they were not being changed either? > >> > >> Hi, > >> I'm not sure what you mean. > >> I was monitoring the status of the ntp using ntpd and the "o" option to se > e the offset and the status of the sources. > >> > >> I was also reading the ntp.drift file to check the drift value. > > > > Unfortunately there is no history for the drift file contents and the tim > es between updates seems irregular. looking around my systems I see > > OSX >1hr > > FreeBSD >5hr > > FreeBSD >2hr40 > > FreeBSD >15m > > linux >1hr:50 > > Windows 7 > 2h > > > > Once it has settled down ntp polls the server every 20 min (approx). But > it then sends that poll through a clock filter algorithm which throws > away roughly 7/8 of the results. (it keeps only that poll item whose > delay is smaller than any of the other delays of the last 8 polls), > which brings you up to roughly 2.5hr. between updates.
Bill, you say this a lot. The experience we have is that the longer the delay the larger the error, and ntpd does its best to set the time based on the highest-quality time samples it can find. >> I haven't looked at the source, but it may mean that ntpd updates the >> file only when there is a change in frequency, say due to temperature >> variations, but this is not systematic as if you check the frequency >> with ntpq -rv, you get data that can differ from the value in the >> file . There must be some time factor as well. > > ntpd changes the offset ONLY by changing the frequency. Thus if there is > a non-zero offset, the frequency is changed ( and the offset is "never" > zero). Ie, anytime a new poll result makes it through the filter, it > changes the frequency. This has nothing to do with the author's question about the drift file, which is updated once an hour iff there has been a significant change since the last time it was written. See the code around line 259 of ntp_util.c in ntp-dev. > > example: > > mike@raspberrypi ~ $ sudo ls -l /var/lib/ntp/ntp.drift > > -rw-r--r-- 1 root root 8 Dec 5 00:51 /var/lib/ntp/ntp.drift > > AIUI, it does not write out the drift file every time it changes the > frequency. > The drift file is there to give an approximate value for the drift of > the system for next bootup. Since the new drift will certainly be > different from the present drift (temperature, recalibration of the > system clock, wear on the crystal, ....) it is pointless to have the > file follow the current drift to closely. And the system clock recalibration of what used to be the "tick" value pretty much only happens on Linux kernels (and this may have been fixed recently). The drift file value is tightly-coupled to that "tick" value. That value was a constant most everywhere until [some version of the linux kernel] when somebody had the idea that the frequency needed to be calculated at each boot. This means that from one linux boot to the next the tick value can change by about 200ppm (as I understand it), and these changes mess up the stored drift calculation. Yes, we could do something about this, but nobody has volunteered to do this work. H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
