NTP diftfile

[Mostafa Yasin]

Hi all;

I have configured NTP service as a server using Red Hat Enterprise 5 and it is working fine.

could you please tell me the function of the driftfile called /var/lib/ntp/drift with an example?

Please be informed that i have read a lot of documentation about this file including "man ntpd" but i didn't understand anything.

Best regards....

[Tim Nelson]

this file is typically used to adjust for slightly inaccurate clock frequencies..All computer clocks are inaccurate to some degree based on number of influences.

If you are really interested in supplying the correct time to your environments, I would do one of two things.

1) purchase an atomic clock of some type and hook up to this server.

2) have your primary server query a number of the internet time servers ( that use atomic clocks) then have all your servers query your primary server.

[Mostafa Yasin]

Dear Mr. Tim;

Thank you very much for your answer.

Could you please give me an example to clear for me the function of the driftfile?

Best Regards...

[Matti_Kurkela · Accepted solution]

I'll try:

When the NTP service is started for the first time, contacts all the configured time servers, gathers some statistics and synchronizes with the one that seems most reliable. NTP tries to measure the round-trip time when accessing the time servers, and automatically compensates for it. This is made more complicated by the fact that the accuracy of the local system clock is not known at this time.

After the NTP service has achieved synchronization, it starts to monitor the system's local clock and adjust it so that the system time is brought to agreement with the time server. At the same time, the NTP service gathers statistics from the behaviour of the system's local clock.

When this has been going on for a while (I think at least 24 hours?), the NTP server looks at the local clock statistics and thinks: "Hmm, the local clock of this system seems to be a little slow/fast. It tends to drift -/+ X parts-per-million out of true time."

This drift value in Parts-per-Million is exactly what is written in the drift file.

For example, if the value in the drift file is -10.0, it means that the system clock is slow, and will "drift" 10 millionths of a second per second if running uncorrected on its own. This is equivalent of the system clock being slow by 0.864 seconds per day.

(-10/1 000 000) * 60 s/min * 60 min/hour * 24 hours/day = -0.864 s/day

When the system is rebooted, this process begins all over again... but with one difference: this time the NTP service can read the drift value for the system clock from the drift file at the very beginning, and compensate for the inaccuracy of the system clock. This eliminates much of the uncertainty in the time calculations that happen when the NTP service is synchronizing with the time servers, and thus allows it to achieve synchronization faster.

Also, if the time servers are unreachable after the system reboot, the NTP service can apply the correction factor stored in the drift file to the system clock even when no services are reachable. Making this correction makes the system clock more accurate, although it's not as good as when the service can synchronize with a reliable external time server: the value stored in the drift file is an average, and the behaviour of the system clock can depend on things like the server's workload or operating temperature.

MK