[ntp:questions] Re: [Bug 177] Clock stepping messes up frequency. (fwd)

David L. Mills mills at udel.edu
Sat Oct 25 03:05:26 UTC 2003


You are indeed correct. In my dirty rotten laziness I eyeballed the
wrong column. I just spent the whole day taking apart your data line by
line and correlating the peerstats and loopstats, then wrote a lengthy
line-by-line analysis. Dammit but some crazy message to my own mailbox
that I was reading during a break crashed Netscape and I lost the
message and all that work. Grrrrrr.

The bottom line is that the varmit started off just fine, then an
apparent -2.43 PPM frequency warp showed up. All four of your servers
showed substantially the same thing, leading me to suspect your hardware
clock frequency took a hike. In an interesting wrinkle, the first update
following the onset of the warp flipped the popcorn spike suppressor, so
that update was discarded.

The next update was now 128,000 seconds since the last one, so the time
was stepped and the frequency wiggled a small, nominal amount. The loop
switched to TSET state. However, the first update following that also
exceeded the step threshold and the state machine switched to FREQ
stats. That caused a forced wait for 900 seconds while updates were
ignored. The first one following the wait got the frequency and time
nominally correct and things settled down nicely.

The problem is, if the above analysis is correct, what caused the -2.43
PPM warp in the first place? The warp lasted the better part of two days
and gradually attenuated. The analysis is consistent with a frequency
warp, but there could be some wierd time step that mimicked the warp.

You're in the twilight zone here at the extreme of the expected
performance envelope. I've had good luck here at long poll intervals on
a low-jitter LAN, but your jitter is much worse. Even so, the discipline
algorithm and state machine did what was expected given the assumption
of a frequency warp. I'm suspicious even of that, since I've never seen
a clock oscillator take a warp of that magnitude short of tossing the
machine outdoors during an ice storm.

If you are still up to it, start the machine in good times and nudge it
from ntpdc to "disable ntp". That opens the loop and it runs free
forever more. Statitistics are still collected, so if the trouble is a
bent oscillator, you will see the warp right then and there and without
NTP doing anything except constant frequency.


Roy wrote:
> "David L. Mills" <mills at udel.edu> wrote in message news:<3F988ED3.CDA4BB28 at udel.edu>...
> > Roy,
> >
> > You have a classic case of huf-n'-puffitis. The delay varies throughout
> > the day starting at moderate values near day's beginning rising to 0.8
> > second near second 70000 then falling to a few tens of milliseconds
> > until day's end.
> Pardon me Dr. Mills, but aren't those values in the dispersion field
> and not the delay field?  It might be easier to check the files I
> e-mailed to you.
> BTW, it seems to me that the dispersion calculation generates insanely
> high values at high poll intervals.  It just makes no sense to me that
> the dispersion should be 835 ms. just after a poll with a delay of
> less than 34 ms.
> Have a great time,
> roy
> --
> The suespammers.org mail server is located in California.  Please do
> not send unsolicited bulk e-mail or unsolicited commercial e-mail to
> my suespammers.org address or any of my other addresses.  These are my
> opinions, not necessarily my employer's.

More information about the questions mailing list