[ntp:questions] Writing the drift file
terje.mathisen at tmsw.no
Fri Mar 6 16:39:28 UTC 2015
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
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.
The latter value can probably be calculated:
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
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.
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
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions