Subject: Re: "frequency error ... exceeeds tolerance"
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Greg Troxel <firstname.lastname@example.org>
Date: 08/21/2007 13:08:07
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
> 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,
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----