[ntp:questions] Writing the drift file

Jochen Bern Jochen.Bern at LINworks.de
Fri Mar 6 13:02:54 UTC 2015

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?

*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
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

More information about the questions mailing list