[ntp:questions] Writing the drift file

Magnus Danielson magnus at rubidium.dyndns.org
Sat Mar 7 11:41:47 UTC 2015


On 03/06/2015 10:35 AM, Harlan Stenn wrote:
> Folks,
> 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.
> Somebody came up with an interesting way to do this that involves
> looking to see how much the drift value has changed and only writing the
> value if the change was "big enough".
> By my read of the code and the comments:
> 1) it looks like the code is implementing something other  than what the
> comments want, and
> 2) what's described *or* implemented seems way more complicated than
> what we need.
> 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?

For embedded systems, reducing the rate of writing make sense, so in 
this regard the question is valid IMHO.

There can't be a universal limit that will once and for all satisfy all 
needs, so some user configurability would make sense.

Another aspect is that if a drift-file exists, NTP believes it and skip 
the frequency track-in phase and does not resolve the resulting constant 
reset of time that will be a result of not being able to track in the 
difference between the given offset and actual offset, if it is too 
large (this addresses Jochen's 3rd point about worst case scenario). I 
discovered this the hard way some years back, but I think it never got 
resolved. Anyway, as long as this misfeature remains, lowering the 
drift-write rate could lead to subtle misconfiguration issues worse than 
existing drift-file issues. This would limit the range of values users 
could configure and it would also end up expose the existing misfeature 
since we need to make sure that there is a very high likelihood that the 
drift-value written is within the capture range of the PLL mode, even 
when written more seldom.

Trying to modify the way NTP write (Joochen's point 1) does not help for 
flashes, it's the write itself which may be long-term destruction, so it 
is reducing the rate of write which should be the key. It might be 
better to do the write as part of shut-down.

In general, the drift-file handling should be made more fool-proof 
first, before attempting to improve the write rate issue. It has already 
proven itself causing a number for problems, but rather than addressing 
it directly, trying to address triggers seems to be the main problem. 
Until this is done, the drift-file can be a beneficial accelerator for 
systems where it works, but may be discouraged for other system uses. 
It's main motivation is to overcome the FLL phase time of NTP start-up.


More information about the questions mailing list