--=-=-=


der Mouse <mouse@Rodents.Montreal.QC.CA> writes:

>> Maybe, but things are messy enough that I'd be wary of any
>> conclusion.  NTP on the wire has various fixed-point formats,
>> designed to be big enough for the need.  The kernel pll has the same
>> mentality.  I wouldn't be all that surprised if something were
>> wrapping.  500 really is wacky - normally even 100 is bad.  See
>> /usr/include/sys/timex.h.
>
> MAXFREQ from <sys/timex.h> is 512, and...

Right - that's supposed to be so far away from any reasonable clock that
it never hits the test.

>> I'd run /usr/sbin/ntptime and see what that says.
>
> ...ntptime says, among other things, "tolerance 512 ppm".
> Interestingly, the messages in /var/log/messages show numbers from -512
> to -501, and 501 to 512, but nothing else - I wonder what's going on
> there.  (There's also a bug in sort -n, which I will send-pr; it sorts
> in order -510, -512, -511, -500, -509, -508, -507, -506, ..., -502,
> -501.)
>
> I'm now collecting output from ntpdc -c loopinfo and ntptime both, once
> a minute.  What are the most interesting figures?

well, basically watching the frequency error as a function of time and
seeing if it wanders or if it's stable.  And the estimated error, which
is NTP's estimate of how well converged it is.

ntp_gettime() returns code 0 (OK)
  time ca759a48.092178f4  Tue, Aug 21 2007 13:07:20.035, (.035667231),
  maximum error 74634 us, estimated error 345 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -225.541 us, frequency -11.963 ppm, interval 1 s,
  maximum error 74634 us, estimated error 345 us,
  status 0x2001 (PLL,NANO),
  time constant 10, precision 0.001 us, tolerance 496 ppm,

> ntpdate -q?

yes, that looks like the right thing.


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGyxv3+vesoDJhHiURAscgAJ9FxzOHKrqRVZMZQdZ+72E3ThmJvQCfU53u
FUrhZVmjvxilf03Wvg+EUEM=
=fz7U
-----END PGP SIGNATURE-----
--=-=-=--