[ntp:questions] Isolated Network Drift Problem
Richard B. Gilbert
rgilbert88 at comcast.net
Tue Nov 25 19:21:18 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
>> 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
>> 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
> 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
>> 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
>> [root at fluid root]# cat /etc/ntp/drift
>> ##?? 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