ntp.drfit file

[Donny Jekels]

how tight can I go with the drift file without causing the pendulum to stop and hence causing xntpd to crash?

mine is now set at
5.287 0

any ideas welcome

[Michael Steele_2]

24 hours is recommended.

The drift file is used by the xntpd daemon to collect a day's worth of errors during syncing. An average is determined and used at bootup.

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90147/B2355-90147_top.html&con=/hpux/onlinedocs/B2355-90147/00/00/60-con.html&toc=/hpux/onlinedocs/B2355-90147/00/00/60-toc.html&searchterms=file%7cdrift&queryid=20030429-173355

[Bill Hassell]

The drift file should be created as a zero-length file and let xntpd manage the contents. xntpd is a very complex protocol and messing with the control files will definitely cause problems. If you do nothing, xntpd will (over a long time period) maintain your time to less than 128ms accuracy. This of course is very dependent on the stability of your time servers (notice: multiple servers (3 or more) are always recommended) and delays throughout the network paths.

To see the current accuracy of your client, use the command:

ntpq -p

The reach value should be 377 (a measure of the communication reliability to the site, 377 is the maximum). Anything significantly less than 377 will not provide an accurate source, especially if it is the only time source.

xntpd will never step-change the time but will instead make the clock run just slightly slower or faster in order to catch up. xntpd will ensure that every day has the correct number of seconds every day. Loss of time servers will cause no problems as xntpd will make no adjustments until the servers are available, and will ignore time values from servers that are dozens of minutes out of sync with the local system, the idea being to never jump the local clock incorrectly.