[ntp:questions] Isolated Network Drift Problem

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


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

>On Tue, 2008-11-25 at 18:22 +0000, Unruh wrote:
>> cwebster at ec.rr.com (Cal Webster) writes:
>[...]
>> >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.

>*chuckle* :-)
>Okay, thanks for clarifying that. It's faster for me to copy the
>command, along with the carriage return. Then I just click the middle
>mouse button to paste at 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. 

>Okay, so I'll just be using the difference in seconds between one
>invocation of "date" and the next.

>How do I translate these seconds into a usable value for "ntptime -f"?

1sec/day=11.47 PPM. scale for other values. 
(Ie, convert the time difference to seconds per day, and multiply by 11.5)
If the computer time is fast you need to slow down the computer clock.




>[...]

>> >##>> Wait 4 days (Thanksgiving day weekend)
>> 
>> That will give you the averaged rates to about 3PPM at best.

>Okay, so would you suggest a week or more? I would be happy to get to
>within one second per day right now. We have no critical systems
>requiring microsecond accuracy. I just need to keep pretty good time so
>logs match up and "Make" dependencies work between NFS mounted resources
>on development hosts. 

>[...]

>> >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

>I wasn't aware that I had illustrated any level of accuracy. As I said,
>I'm shooting for about 1 sec per day.

20.196 is a number which seems to be accurate to .001 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. 

>I'll look at "chrony" but I want whatever NTP implementation we use to
>be as maintenance free as possible once it's in operation. I don't want
>someone to have to manually update anything every day or week.

Well, that daily or weekly input of the time is to keep your system on
time. It will drift. And if you want to correct that drift youhave to give
it more data. 



>[...]

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

>Okay, so I'm just going to calculate the difference in seconds between
>the system time and my Internet reference, then somehow ("ntptime -f"
>maybe?) tell the kernel to use a different frequency offset.

>> >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. 

>That's what I'm asking. Is there a kernel parameter to set frequency
>offset? If not, how do I make the calculated offset persist across
>reboots? Aside from a kernel parameter entry in /etc/sysctl.conf the
>only way I can think of is to add the full comand "ntptime -f (offset in
>PPM)" to "/etc/rc.local" or "/etc/rc.sysinit".

You could do that. 

Note that the recent linux kernels have apparently totally messed up the tsc hardware
clock. The drift rate changes by 50PPM between successive reboots, so you
old drift file is useless on the new boot. You need to make sure that the
machine use the acpi_pm (?) or hpet as their timing source, not the tsc. 





More information about the questions mailing list