[ntp:questions] Re: NTP clients not throttling back is this behaviour RFC compliant?

David L. Mills mills at udel.edu
Wed Dec 3 21:21:02 UTC 2003


Terje,

You describe in fact what I did for the Alpha kernel now in Tru64. On
the assumption not all processors on a single machine may not run at the
same clock rate, each one has to be disciplined separately, in my case
relative to the timer seconds rollover. As you cannot predict which
processor actually reads the time and each one has its own idiosyncratic
PCC (ALpha TSC), each processor has its own estimators and all have to
be disciplined once per second using interprocessor interrupts.

There is at least one installed Alpha with thirteen (!) processors using
the code. The code is in the stock kernel, but has to be enabled and the
kernel rebuilt. I had to confirm by simluation that evil little
glitches, due tiny frequency and phase mismatches, are suppressed and
time is always monotonic increasing.

I didn't see the need for further filtering the PCC estimates, but if I
did I wouldn't use simple averaging. A median filter is much better for
tossing out popcorn spikes. What I find scary now is the little things I
ignored then as in the noise might not be in the noise any more. If
processor clocks get much faster, the resolution may soon be limited by
the NTP format itself, which is about 232 picoseconds. The time to cycle
through the Solaris kernel to read the time on a Blade 1000 is now about
400 ns, so some things I ignored in the ntpd code has had to be
reexamined and reworked, most recently the poll-adjust algorithm.

Fifteen years ago the ambitions goal was to the millisecond and that
required special hardware for the Fuzzball. Now it is to the nanosecond,
which is a thousandfold improvement in resolution and we do that even
with junkbox PCs.

Dave

Terje Mathisen wrote:
...
[text deleted by fascist news system]



More information about the questions mailing list