[ntp:questions] NTP Performance on WINNT
unruh-spam at physics.ubc.ca
Mon Jul 27 23:19:03 UTC 2009
David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
>> In other words, there is a random noise component to the "software clock
>> time" and to the measurement of UTC via the net, or whatever, and that
>In the estimate of the time on the servers and peers. There will also
>be an error term from reading the local clock, but it ought to be less,
>if only because the time from servers will start with that error term,
>for their clocks.
>> ntp, by averaging over a number of measurements, can reduce that random
>> uncertainty. This assumes that the noise sources are random gaussian
>> noise. In general many are not. Thus this is subverted by ntp's slow reaction time ( so
>Which is why I qualified my statement by saying that it only applied in
>the enviroment Dave Mills expects ntpd to operate in.
David expects it to operate in all sorts of strange environments. He did
make assumptions as to the form the noise, and it is not clear how good
they are. Some he recognizes-- the highly non-guassian nature of the
packet delays which he tries to mitigate with the "clock filter
algorithm in which he throws away about 85% of the data he collects-- or
the huff and puff filter. What he does not mitigate is the highly
correlated clock rate change due to temp changes. This ntp is very bad
at handling. Once you get to microsecond accuracy, this dominates the
errors, and it is not guassian, or 1/f.
Note that he certainly expects ntp to operate on computers which are
actually used for doing useful work, which are also computers on which
the temperature problems are most severe.
>> it does not track changes in the clock drift due to temp variations
>> well) so that often (usually) UTC-clock >~ offset.
More information about the questions