[ntp:questions] Re: New to NTPD
Richard B. Gilbert
rgilbert88 at comcast.net
Wed May 10 00:29:15 UTC 2006
Ted Gervais wrote:
> Thanks Brian for your input on this matter. Sure need something right
> now and your input surely looks helpful.
> Now - what I have in place right now shows some improvement but I wonder
> if it is right yet. Here is what ntpq -p gives me:
> Every 1.0s: ntpq -p Tue May 9
> 19:42:06 2006
> remote refid st t when poll reach delay offset
> +clock.via.net .GPS. 1 u 223 256 377 101.718 21.183
> gnomon.cc.colum .USNO. 1 u 483 1024 301 55.229 26.100
> -NAVOBS1.MIT.EDU .PSC. 1 u 11 256 377 60.820 28.740
> +ntp3.usv.ro .PPS. 1 u 15 256 377 173.654 26.977
> *clock.xmission. .GPS. 1 u 216 256 377 88.717 23.674
> +c-24-130-58-99. .GPS. 1 u 83 256 377 118.072 23.165
> How does this look? I think it actually is working now?? Anyone, please
> let me know.
> And Brian... I will try the list of servers that you provided. Thanks
> very much for that input..
You seem to have very large round trip delays to the servers you have
chosen. Shorter delays are better. The error in transmitting time from
server to client is bounded by one half the round trip delay. With a
delay of 173.654 milliseconds, all you know is that the error can't be
worse than 86.3 milliseconds.
Look for servers close to you in net-space; i.e. those with low values
for delay. I look for delays of fewer than twenty milliseconds and have
found five servers that meet this test. If I could not find sufficient
servers meeting the twenty millisecond objective, I would relax my
standards until I could find five servers.
ntpd has selected a server for synchronization, clock.xmision. The
asterisk preceding the server name indicates that it has been selected.
The offsets are still large but I don't think you had been running
very long when you got this output.
More information about the questions