[ntp:questions] Writing the drift file

William Unruh unruh at invalid.ca
Sat Mar 7 18:07:54 UTC 2015

On 2015-03-07, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
> Harlan,
> On 03/07/2015 12:12 PM, Harlan Stenn wrote:
>> OK, a fair amount of good stuff is being discussed.
>> Do we mostly all agree that the purpose of the drift file is to give
>> ntpd a hint as to the frequency drift at startup?
>> If so...
>> The current mechanism is designed to handle the case where ntpd is
>> restarted fairly quickly, so there's a good chance the same drift value
>> will work.
> Remember that for embedded devices, the operational conditions may be 
> such that it's not a "quick restart" at all times. You cannot assume and 
> know when it will go up the next time after being powered off. It can be 
> minutes, hours, weeks, years.
> Just like the leap-second file, the time of the drift-file is relevant, 
> and if it is "too old", it is one (of several) reasons to disqualify it.
> Relying on the time-stamp of the file can be trouble-some, as it may not 
> be respected by file-management. Writing it into the file is more robust.

I suppose one could have ntpd calculate several drifts-- averaged over
now, 1 hr, one day, one week and record them into the drift file, and
have ntpd pick which one to use based on the current best estimate of
the time elapsed since the drift file was written ( which could be
stored in the file as well.) The question is whether or not the
additional complexity in the file and the added code to ntpd would be
worth it. Most programs grow by this kind of gradual accretion.
"Wouldn't it be nice if the program did this" and it is implimented (it
is not that hard to stick it in) even if "this" is only used by one
person in a million. And gradually the program becomes an unsupportable mess,
with bugs hiding all over the place.

More information about the questions mailing list