[ntp:questions] Writing the drift file
unruh at invalid.ca
Fri Mar 6 20:41:49 UTC 2015
On 2015-03-06, Terje Mathisen <terje.mathisen at tmsw.no> wrote:
> Jochen wrote such a nice synopsis that I can only add my vote for a
> single write of the average drift over a long time period, i.e. somthing
> like this:
> a) Collect and average the values that would have been written every
> hour, then write this out to the file system after 24 or 48 hours, i.e.
> long enough to average out any day/night or AC changes.
> b) Write a new value every week, but only if the average has changed sp
> much that the control loop can overshoot after a full restart.
Often the drift file is used, not on computers that are shut down for
days at a time, but briefly. (eg a crash, or maintainance shutdown).
Then you would want the current drift when you start up again. Ie, the
useage profile varies.
> The latter value can probably be calculated:
nptd does not like to remember stuff. This would demand that it remember
the drift over long time periods (of course on could do the averaging by
adding in some tiny fraction
avdrift= (1-e)*avdrift +e*currentdrift.
and this would effectively average over 1/e periods.
And e could be user selectable via a fudge factor, between 0 and 1. )
> We know that a modern ntpd will handle a missing drift file much better
> than a badly wrong one, so lets start with a drift file which is 100 ppm
> in error:
> This results in an offset of 26 ms in 4 polling period of 64 seconds
> each, so even with a default minpoll 6 value we will not go outside the
> 128 ms limit before active steering fixes the bad drift value.
Well, no that forgets the clock filter algorithm. With poll 6 the
measurements are 64 sec apaprt, but the selected ones are more like 8
min apart (smallest delay of the past 8) . That would certainly send the clock out of bounds.
> Jochen Bern wrote:
>> On 03/06/2015 10:35 AM, Harlan Stenn wrote:
>>> A while ago we got a request from the embedded folks asking for a way to
>>> limit the writing of the drift file unless there was a "big enough"
>>> change in the value to warrant this.
>>> I'm wondering if we should just let folks specify a drift/wander
>>> threshold, and if the current value is more than that amount we write
>>> the file, and if the current value is less than that amount we don't
>>> bother updating the file. If folks are on a filesystem where the number
>>> of writes doesn't matter, no value would be set (or we could use 0.0)
>>> and it's not an issue.
>> *Thoughts* I have, but no clear conclusion, I'm afraid ...
>> 0. There's "limiting" the write ops, and then there's being all out to
>> avoid them. Saying that the value should *never* be written unless the
>> difference exceeds the threshold suggests the latter, is that actually
>> the request? From a sanity POV, *some* timeout (say, a month) and/or
>> writing triggered on orderly shutdowns sound like something we'ld want
>> to do.
>> 1. What about *appending* to the file (up to some length limit) instead
>> of overwriting the exact same bytes within it? Is that something that
>> flash RAM and its specialized fs'es can handle better?
>> 2. What's actually the worst-case scenario here? Let's assume a unit
>> whose drift is correlated with the 24h temperature cycle, -6 ppm at
>> daybreak, +6 ppm in the early afternoon, and the limit is a delta of 10
>> ppm. Now, if the drift file gets initially written with an intermediate
>> value of abs(x)<4, it'll *never* get rewritten - but otherwise, there
>> will be two writes per day for all eternity, as the mechanism doesn't
>> allow the stored value to ever gravitate to the middle ground. Is that
>> something that should be taken care of?
>> 3. What's the purpose of that stored value? IIUC ntpd only ever reads it
>> on startup, and the inherent assumption is that it is a fairly *RECENT*
>> drift value that ntpd can assume to be a proper approximation of the
>> *current* drift, and compensate for it. With the new mechanism, the
>> actual current drift is somewhere within +/-limit of the stored value.
>> Is that still useful, as in minimizing the offset that the starting ntpd
>> will pick up until it has obtained a drift estimate of its own? Or would
>> it be better to have it start with some sort of *average* value of the
>> drift, rather than a "current" value that actually isn't ... ?
>> J. Bern
More information about the questions