[ntp:questions] Isolated Network Drift Problem

Unruh unruh-spam at physics.ubc.ca
Tue Nov 25 18:22:28 UTC 2008


cwebster at ec.rr.com (Cal Webster) writes:

>On Tue, 2008-11-25 at 09:25 +0100, Maarten Wiltink wrote:
>...
>> [...]
>> > What's the best way to determine which of our NTP servers provides the
>> > best local clock?
>> 
>> First order: reset drift (delete all their drift files), synchronise their
>> watches, let them run for a few days, and see which one has drifted least.
>> Correct for drift.
>> 
>> This depends on how well you can put them all in the same starting state
>> by hand, and on the time source you use to measure drift at the end. You
>> can correct for the former by waiting longer. You _cannot_ outwit your
>> dependency on the latter.
>> 
>> Second order: after the previous procedure, they should all drift very
>> little, and no one significantly more than any other. The one that stays
>> closest to that time source you're comparing against has 'the best local
>> clock'. This depends mostly on temperature stability.

>So, to recap:

>##>> Delete the NTP drift files.


>##>> "Synchronizing" their clocks:

>1. Stop NTP daemon
>2. Consult http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/
>3. Construct a "date" command with the next minute after what's observed
>in step 2 and zero seconds.
>4. Copy the date command and watch the count-up to the next minute on
>greenwichmeantime.com.
>5. Paste the date command into the terminal window exactly when the

No, you can have it in the window all the time. Just hit return on the 00
sec.


>counter turns to the next minute on greenwichmeantime.com.
>6. Execute "hwclock --systohc" to set the hardware clock.
>7. Start NTP daemon

No, do not start the ntp daemon. It is useless in this situation. After a
few days, run date again comparing it to the time. 

Again how are you getting to the internet to "Consult
http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/"?
Why not just connect to the internet with the ntp network while you are
testing it? Much easier and faster. Then you can run ntp and look at the
offsets  and the frequency in the ntp log files and see which one behaves
better.


>Repeat this for each NTP server


>##>> Wait 4 days (Thanksgiving day weekend)

That will give you the averaged rates to about 3PPM at best.



>##>> Record value in NTP drift files



>Ex:
>[root at fluid root]# cat /etc/ntp/drift
>20.196

>##?? Is this a good source to measure the drift?


>##>> Correct for the drift:

>ntptime -f 20.196

No way you will get that kind of accuracy using this procedure.
You will be lucky with a few PPM

Alternatively you can run chrony, and it will do all of this for you (Ie
you enter the current time from you wristwatch or whatever, and a few days
later do so again and again and it will calculate the freq offset and
offset for you and correct your clock. Then every weekend or day you can enter
your wristwatch time again and it will keep refining the corrections. 


>-or-
>adjtime -f (result of some formula)

>##?? Not sure about the signage here. From what I've read, the value
>stored in the drift file is the frequency offset - the value required to
>bring the clock back to normal.

>##?? Should this be done with ntpd stopped or running? From the man page

ntp stopped.

>it seems this command communicates with the running kernel. Is there a
>kernel parameter I can set in /etc/sysctl.conf to make this setting
>persist? The only thing I can see related to the clock in /proc is
>"/proc/sys/dev/rtc/max-user-freq".

What setting? Note that chrony will also try to estimate the RTC errors for
you and recalibrate the clock depending on those errors when you start up
again. Ie, it sounds to me like chrony is a far better tool for your use
than ntp is. 




>##?? Is this what you had in mind?

>Thanks!

>./Cal




More information about the questions mailing list