Unruh wrote: > [EMAIL PROTECTED] (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: >> [EMAIL PROTECTED] 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! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
