[ntp:questions] Isolated Network Drift Problem

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

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

>On Wed, 2008-11-26 at 00:52 +0000, Unruh wrote:
>> >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.
>> >> >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.:-)

>Oh, I see what you're saying. All I did was to pull the number
>from /etc/ntp/drift (ntpd's drift file) and paste it into the ntptime
>command. Doesn't the "-f" argument specify frequency offset and the
>drift file contains the frequency offset calculated to that point?

IF you are on local clock or are a client to a machine on local clock, then
that drift file means nothing at all. You HAVE to have an accurate time
source to have a meaningful drift file. And if you are running Linux with
the tsc clock, the drift will change by 50PPM between reboots (bug in
implimentation) so the drift file is also useless if you reboot.(50PPM is
about 5 sec per day)

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

>1 minute every couple of months would be fine.

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

>Thanks for that info I'll keep that in mind. Well, in my notes
>anyway. :-)


More information about the questions mailing list