[ntp:questions] Isolated Network Drift Problem

Unruh unruh-spam at physics.ubc.ca
Wed Nov 26 00:45:44 UTC 2008


"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>Unruh wrote:
>> 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. 
>> 

>Keep in mind that "wristwatch time" may be accurate to within a few 
>hundred microseconds but it is unlikely that you can enter this time 
>without introducing an error that might be as large as 500 milliseconds!

No, anticipatory hitting of the return key can get it better than 500ms. I
would estimate to within 100ms. Mind you if that timezone clock is a
thousand KM away with a number of switches between, it will probably take
that 1/2 sec to actually display that correct time on your screen. 





More information about the questions mailing list