On Tue, 2008-11-25 at 18:22 +0000, Unruh wrote: > [EMAIL PROTECTED] (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: > >[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 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". _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions