[ntp:questions] Writing the drift file

David Taylor david-taylor at blueyonder.co.uk.invalid
Sat Mar 7 12:11:26 UTC 2015

On 07/03/2015 11:12, 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.
> The reason for this is to get faster startup times.  If the value in the
> drift file is "close enough" and the system is using iburst, ntpd will
> synch the clock and be ready to go in about 11 seconds' time.  Otherwise
> it can take 5 minutes or more.
> If conditions are such that the value in the drift file is not "close
> enough" to the correct value then we're looking at needing 5 minutes or
> more to get the clock sync'd.
> How much effort should we go thru to handle some of these situations?

I'm inclined to say "not a lot".  I mean: (a) there's likely to be 
something writing far more than a few bytes every hour, and (b) what 
write rate is or is not acceptable in any case?

I see the life of SSD cells quotes in the region on hundreds of 
thousands, and that's something like 11 years at one write per hour (if 
my maths is correct).  But SSDs and other devices take great pains /not/ 
to write to a single cell repeatedly, so the life at a few bytes an hour 
is likely to be grossly in excess of 11 years.

Perhaps an option /only/ to write when NTP is closed normally may be 
worth adding, in addition to the "only write if drift is significantly 
different".  Two user-tunable options: write-only-if-different, 

But as it is I think is quite reasonable.

Web: http://www.satsignal.eu

More information about the questions mailing list