r3 - 2015-03-09 - 09:50:02 - MikeCookYou are here: NTP >  Dev Web > DevelopmentIssues > NtpDriftFileNotes
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

NTP Drift File Notes

Related Topics:


ntpd has long had the option of writing a drift file, usually ntp.drift. The value written there was the recent frequency adjustment ntpd was using to keep the clock in sync. This file was usually updated once an hour.

ntpd initializes its frequency adjustment based on the value stored in ntp.drift and if this value turns out to be accurate, ntpd will achieve SYNC in about 11 seconds' time. If not, or if there is no ntp.drift file, ntpd will embark on a 900 second (minimum?) analysis of the clock to determine the offset and frequency corrections.

If "enough" time has passed, or perhaps more accurately, if environmental conditions have changed significantly since the ntp.drift file was written, the value we'll use to predict the current frequency drift will be incorrect and ntpd will need to do a full-on analysis of the clock to determine the offset and frequency adjustments.

It will take a decent mount of work and effort to determine the amount and type of information we'd want to keep in the ntp.drift file to have the initial drift estimate be "good enough" in a wider range of situations. It is doubtful the added complexity will be worth it, especially with new startup schemes emerging.

Additionally, expanding this scope will likely require temperature data that is generally not available.

The primary reason to avoid writing the ntp.drift file every hour is that a number of embedded platforms want to avoid as many writes to the filesystem as possible.

We could only write the drift file on an orderly shutdown, but a) that doesn't mean the value has changed significantly, and b) there are plenty of times when ntpd will not be able to perform an orderly shutdown.

  • The ball park drift is known fairly soon after start up ( 900s max) and after that will only change by a relatively small amounts, say an order of magnitude or less than the initial estimation.). So it could be written early and then forgotten. -- MikeCook - 09 Mar 2015


The goal of the ntp.drift file is to turn a 900 second (or more) cold-start into something faster. Currently the best we know how to do is an 11-second startup.

We want to do this writing a new ntp.drift file as infrequently as reasonably possible.


How close does the frequency drift need to be?


Current implementation

The current implementation is documented in the write_stats() function in ntp_util.c .

That documentation says:

When the frequency file is written, initialize the prev_drift_comp and wander_resid. Thereafter, reduce the wander_resid by half each hour. When the difference between the prev_drift_comp and drift_comp is less than the wander_resid, update the frequency file. This minimizes the file writes to nonvolaile storage.

Harlan doesn't think that's what the code implements.

Regardless, this still seems overly complicated.

If we can get a good idea of how close the driftfile must be in order to achieve and hold sync, then perhaps the best we can do is to record the cold-start correction and the range of operational state corrections, and see if we can find a "happy medium".

It is not clear if it's worth this much effort, either...

  • Important to note that it is only helps to achieve sync. Not hold it.

The doc and code comments appear to be wrong, but the implimentation is working as expected. We only re-write the file if the difference between the previous and current values is GREATER than the resid. This works, as for a very stable clock I have a last file update of May 2014.

Could it be improved to further minimise writes without impacting startup times? I think so. Withouth changing the basic implimentation we could fix a lower bound on the absolute value of drift_comp which triggers a write. Say to 10% of the initially calculated/recorded value. -- MikeCook - 09 Mar 2015

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r7 | r5 < r4 < r3 < r2 | More topic actions...
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback