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
jitter
==============================================================================
+clock.via.net .GPS. 1 u 223 256 377 101.718 21.183
5.465
gnomon.cc.colum .USNO. 1 u 483 1024 301 55.229 26.100
2.439
-NAVOBS1.MIT.EDU .PSC. 1 u 11 256 377 60.820 28.740
2.602
+ntp3.usv.ro .PPS. 1 u 15 256 377 173.654 26.977
1.469
*clock.xmission. .GPS. 1 u 216 256 377 88.717 23.674
4.681
+c-24-130-58-99. .GPS. 1 u 83 256 377 118.072 23.165
1.358
-------------------------
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..
<big snip>
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.
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
