[ntp:questions] Isolated Network Drift Problem

Richard B. Gilbert rgilbert88 at comcast.net
Tue Nov 25 19:21:18 UTC 2008


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!




More information about the questions mailing list