David Woolley <da...@ex.djwhome.demon.co.uk.invalid> writes: >Steve Kostecke wrote:
>>> I'm just not so sure if I can absolutely count on ntpq to determine >>> time offset of NTP synced machines... >> >> ntpq does not calculate anything. It merely displays information >> returned from the ntpd it is querying. >> >I believe that he means the combination of ntpq and and ntpd. The basic >problem is that you are trying to mesure a parameter on a system where >that parameter affects the accuracy of the measurement. >There is also a problem that many other people believe that software >clock time + offset = UTC time (possibly minus). However, when ntpd is >operating in the environment in which Dave Mills expects it to operate, >|UTC - software clock time| << |offset|. 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 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 it does not track changes in the clock drift due to temp variations well) so that often (usually) UTC-clock >~ offset. >I believe that the parameter the OP actually wants to measure is |UTC - >software clock time|. As this is Windows, and Windows doesn't >interpolate, one would guess that he wants this value at the point of >the clock tick. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
