Minor issues of time on PPC

[Garance A Drosihn]

At 8:48 AM -0400 7/19/05, Joshua Coombs wrote:
>"Garance A Drosihn" <drosih at rpi.edu> writes:
>
>>I've noticed a few minor issues with tracking the present time
>>on my Mac-mini.
>         <snip>
>>Hmm.  I just noticed that
>>ntpd is running with '-f /var/db/ntpd.drift' -- but that file does
>>not exist.  But then, it doesn't exist on my other freebsd machines,
>>and they all seem to keep accurate time.  Still, I'm going to try
>>creating that file and see if it does any good.
>
>echo 0 > /var/db/ntpd.drift
>restart ntpd

I did these.

>Try this, let the machine run for a couple hours, then email the
>output of:
>
>ntpdc -c loopinfo
>ntpdc -c kerninfo
>ntpq -p

It's been running about 30 hours now (I forgot about it last night),
and time on the Mac-mini is now off by a little more than five
minutes.  Here's the output:

(33)  # ntpdc -c loopinfo
offset:               0.000000 s
frequency:            0.000 ppm
poll adjust:          0
watchdog timer:       106387 s

(34)  # ntpdc -c kerninfo
pll offset:           0 s
pll frequency:        0.000 ppm
maximum error:        53.197 s
estimated error:      1.6e-05 s
status:               2001  pll nano
pll time constant:    0
precision:            1e-09 s
frequency tolerance:  496 ppm

(35)  ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  columbia.       128.59.59.177    3 u  864 1024  377    1.275  302122. 2934.24
  enterprise.     130.207.244.240  2 u  875 1024  373    7.396  302088. 2934.08

A few interesting points here.  For one, here is ntpd -p from my
i386 box (which has been running with only one ntp server), after
that box has been running for almost three days:

(50)  # ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*columbia.       128.59.59.177    3 u  134 1024  377    1.965   -0.540   0.133

My two FreeBSD machines are on the same 100-Mbit switch in my office,
so I wouldn't expect them to come up with such dramatically different
values of offset and jitter when talking to columbia...

Also, the value inside /var/db/ntpd.drift does not seem to change,
neither on my powerPC machine or my i386 box.  (although I just
created it on the i386 box, so maybe ntpd hasn't run long enough
on that one).

I stopped ntpd and started it again, and it didn't seem to do much
of anything wrt changing the time.  I stopped it again, and started
ntpdate instead, and that updated the time correctly.  After doing
that, I then restarted ntpd again.  I ran the queue cmd immediately
after restarting ntpd, and it said:

(52)  # ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  columbia.       128.59.59.177    3 u   13   64    1    1.321   36.700   0.001
  enterprise.     129.6.15.29      2 u   12   64    1    1.178   39.601   0.001

I checked a few other things, and entered the command five or ten
minutes later, and it now says:

(53)  # ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  columbia.       128.59.59.177    3 u   57   64    3    1.262  216.989 180.289
  enterprise.     130.207.244.240  2 u   53   64    3    1.143  228.484 188.883

It seems the offset and jitter are rapidly increasing.

Hmm.  It might be interesting to try the ntpd client that Matt wrote
for Dragonfly, and see how well that works.  That's much simpler code,
and would probably be good enough for my purposes.  Maybe if I have
some time this weekend, I'll try that.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu