On 2015-03-07, Magnus Danielson <mag...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions