David Woolley <[email protected]> writes: >Unruh wrote:
>> >> 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. >> _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
