> Le 6 mars 2015 à 17:39, Terje Mathisen <terje.mathi...@tmsw.no> a écrit : > > 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. > > 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 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. > > Terje
I suspect that this is a non-issue as someone else indicated. Current practice appears to be to open and write each new value to a temporary file then unlink the old and rename the temporary file. This means that a whole new file structure including new blocks is created each time and the old one freed up. So even in the worst case where the same blocks are allocated on alternated file updates, the effective life of the device is doubled. If the object is to just not write the file, then KIS. Add a command option of a fixed start up drift value determined by the integrator. As an extra, to minimize writes add a « learn once only» option which could be an averaging exercise though I am a bit skeptical of that. This would be ok where a device is to be used in a reasonable stable environment as although the median drift of devices of the same architecture can vary quite a bit ( My R-PIs are 35-55ppm, Soekris 8-15ppm, BBBs 32-34ppm), the bounds during operation do not vary by more than a couple of ppm over the day. So having a ball park figure would be sufficient. For sheer luxury, allow a device for the drift file, which would determine the current drift before starting ntpd. Otherwise for devices being started in varying environmental conditions, better to have nothing. > > 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? >> >> *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 ... ? >> >> Regards, >> J. Bern >> > > > -- > - <Terje.Mathisen at tmsw.no> > "almost all programming can be viewed as an exercise in caching" > > _______________________________________________ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
