[ntp:questions] Isolated Network Drift Problem

Cal Webster cwebster at ec.rr.com
Tue Nov 25 19:39:07 UTC 2008



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

[...]

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

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

[...]

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





More information about the questions mailing list