Very Computer

I have 3 Ultra 5's running a shareware version of ntp which provides support
for the Trimble GPS clocks that are attached. Time jumps are quite frequent
which is unacceptable. Ntp.drift file reports value of 512.00 most of the
time. I need a way of improving the time keeping on these machines. Can
anyone help please?

Run ntpq against your machines and get the results of the peers, cv and rv
commands. Then post them to the comp.protocols.time.ntp newsgroup where the
ntp gurus hang out.

--
Jon Baggott
General Dynamics Electronic Systems
"The views expressed are the author's and do not necessarily reflect the
official position of GD or any of its subsidiaries"

Quote:> I have 3 Ultra 5's running a shareware version of ntp which provides
support
> for the Trimble GPS clocks that are attached. Time jumps are quite
frequent
> which is unacceptable. Ntp.drift file reports value of 512.00 most of the
> time. I need a way of improving the time keeping on these machines. Can
> anyone help please?

Clive

What's the temperature movement like where the machines are?

Our SUNs are reporting a 'drift' of 11.561 and the machine room temp is
pretty stable.

martin

My guess is that ntpd wasn't properly set up.  What is your kernel
"dosynctodr" variable set to?  It needs to be set to zero; otherwise,
the hardware clock will override the software clock periodically, and
ntpd won't be able to do anything useful.  It's also possible that in
addition to freeing the system clock from the hardware clock, you need
to tweak the rate of the system clock itself.

You can just all the necessary stuff with the "tickadj" program that
came with ntpd.

Personally, what I like to do is this:

1.  Set dosynctodr to zero and turn OFF ntpd.

2.  Synchronize the time with a reliable source.

3.  Let the system's clock drift freely for a day or so,
    periodically comparing the time to a time server.
    (Put "date ; ntpdate -d -u timeserver" in cron so
    it runs hourly or something.)

4.  Use this data to figure out how your clock behaves on its own.
    Chances are it probably ran a little slow, but how much?  Did it
    lose (or gain) the same number of seconds each hour?  If it
    sometimes runs fast and sometimes runs slow, then it's probably not
    very stable.  Most Sun hardware doesn't have clocks that wander
    forwards and backwards unpredictably, but some hardware does, and
    it can prevent ntpd from working well.

5.  Determine whether you need to slightly speed up or slow down your
    clock a notch by using tickadj.  ntpd can fine-tune the rate of
    your clock, but only by a little bit.  If your clock is too far
    off, you may need to make a course adjustment.

    Different systems behave differently, but the general idea is that
    several times a second (typically 100), the kernel adds a number
    (typically 10,000) to a counter that keeps track of microseconds
    elapsed.  After one second, it should have had 100 interrupts and
    should have added 10,000 to the counter 100 times, making a total
    of 1,000,000 microseconds.  In the real world, the interrupt tends
    to happen slightly less frequently than 100 times a second.  You
    can't change the interrupt rate, but you _can_ change what it adds
    to that register.  So if the interrupt happens an average of 99.72
    times a second, you'd want to change the system to add 10028
    microseconds each interrupt, because 99.72 * 10028 is 999,992.16,
    which is the closest you can get to 1,000,000.

    Anyway, use your measurements from step #3 to determine how fast or
    slow your clock is.  If it lost 20 seconds during the day, that
    means its rate is (86400 - 20) / 86400 times what it should be, and
    that means it may have 99.9768 interrupts per second instead of
    100.  This means you'd need to change the increment from 10000 to
    10002, because 10002 * 99.9768 is about 999,968, which is the
    closest you're going to get to 1,000,000.  This should make your
    drift more like 3 seconds per day, assuming perfect stability.

    Finally, use tickadj to set this new number.  (Don't forget to put
    it in your initialization scripts so it takes effect at reboot
    too.)

6.  Start ntp, and it should do its thing just fine.  You might want
    to empty your ntp.drift file ("cat /dev/null > ntp.drift"), since
    it will be wrong anyway, now that you've tuned things differently.

Hope that helps.

  - Logan