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,
write-only-on-shutdown.
But as it is I think is quite reasonable.
--
Cheers,
David
Web: http://www.satsignal.eu
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
