[ntp:questions] "ntpd -q" is slow compared to ntpdate

Unruh unruh-spam at physics.ubc.ca
Thu Oct 16 23:56:00 UTC 2008


"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>Harlan Stenn wrote:
>> It seems to me a topic related to initially getting the time set on a box is
>> the ability to determine the 'synchronization status' of ntpd.
>> 
>> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
>> been created.
>> 
>> I'd appreciate folks taking a look at that page, commenting and discussing
>> the issues.

>"Do we care about root dispersion?"

>As I understand it, "root dispersion" is the difference between my clock 
>and the atomic clock at the root.  If my understanding is correct, I 
>think we do care about it.  If the absolute value is greater than about 
>100 microseconds I would begin to be concerned.  Others might choose 
>some other value.

Well, no, since if we knew the difference between my clock and the atomic
clock at root, we would get rid of it. It is a very conserative estimate of
what the difference at worst could be.  As such it is a piece of
information but does not allow you to do anything with it, except maybe
find a new server. 100us is a very vary short time and it had better be on
a local net. (Ie, the network transport time on my local net is about
140usec, and that sets a limit on the accuracy estimate of my clock.)

Since I have an atomic clock, I can look at a remote clock gps clock. the
network delay is 45ms, but the offset is only .2ms. The root delay my
system would have to report would be 45ms, even though it would be
disciplining my local clock to better than 1ms. 




>It's probably worth noting that some people care about the correct time 
>while others only care that all their clocks are within a few 
>milliseconds of each other.




More information about the questions mailing list