Prev: ntpd question
Next: slack 13 OpenOffice
From: Thomas Ronayne on 8 Nov 2009 09:36
Looking back over the problems you're having, one thing I've noticed is
that your delay, offset and jitter values look way out of line (and may
-- may -- be a source of your problems). I'm sitting on a dial-up at the
moment (my high-speed connection is 200 miles away right now) and ntpq
-p reports

ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 24 64 377 0.000
0.000 0.001
*64.73.32.134 255.175.234.61 2 u 25 64 377 175.955
-9.592 2.271
+ip-72-167-54-20 192.12.19.20 2 u 52 64 377 243.968
-17.978 13.373
+lime1.adamantsy 72.18.205.156 3 u 1 64 377 200.945
-13.084 17.887

Which ain't great but ain't bad either.

Doing an ssh connection to my server (the one far, far away)

ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 15 64 377 0.000
0.000 0.001
+socorro.dayww.n 64.183.55.54 2 u 221 1024 377 55.792
3.700 0.364
*knowledge.globa 129.6.15.28 2 u 281 1024 377 37.576
-0.972 1.067
+packman-1.isc.o 131.107.13.100 2 u 259 1024 377 89.575
-4.860 0.814

Better.

So, I'm wondering if it would be worthwhile for you to abandon the pool
servers in favor of looking through the lists of stratum 2 servers
available where you physically are, ping them and make a list of three
stratum 2 servers that are electrically closest to you (which will
reduce the delay, offset and jitter values to a minimum for your
physical and electrical location. There is a list of stratum 2 servers
at http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers that
may be useful (look for your country code).

The "best" (a relative term) may be at universities, state or province
sites, possibly some others -- the thing you're looking for is the
shortest ping time; e.g., the ping time for the stratum 2 server that
I'm currently synchronized to

ping -c 5 64.73.32.134
PING 64.73.32.134 (64.73.32.134) 56(84) bytes of data.
64 bytes from 64.73.32.134: icmp_seq=1 ttl=55 time=44.7 ms
64 bytes from 64.73.32.134: icmp_seq=2 ttl=55 time=39.4 ms
64 bytes from 64.73.32.134: icmp_seq=3 ttl=55 time=38.8 ms
64 bytes from 64.73.32.134: icmp_seq=4 ttl=55 time=38.7 ms
64 bytes from 64.73.32.134: icmp_seq=5 ttl=55 time=39.0 ms

--- 64.73.32.134 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 38.715/40.174/44.761/2.314 ms

NTP is going to have a tough time synchronizing when the delay, offset
and jitter values are huge (matter of fact, it just flat won't).

Hope this helps some.
From: root on 8 Nov 2009 11:48
Thomas Ronayne <trona(a)ameritech.net> wrote:
> NTP is going to have a tough time synchronizing when the delay, offset
> and jitter values are huge (matter of fact, it just flat won't).
>
> Hope this helps some.

I managed to get the daemon working after I changed the tick
value to get the clock close enough for ntpd to take over.
In fact, the new tick value makes the clock accurate enough
that I probably don't need ntpd.

nptd syncs up to different servers every time I boot. The
jitter values change accordingly, so I guess I win some
and lose some. I am happy with how the problem was resolved
and give thanks to everyone, including you, who helped.
From: Bud on 8 Nov 2009 13:56
Thomas Ronayne wrote:
>
> NTP is going to have a tough time synchronizing when the delay, offset
> and jitter values are huge (matter of fact, it just flat won't).
>
> Hope this helps some.

Here are a list of time servers http://tf.nist.gov/tf-cgi/servers.cgi
that use WWV in Boulder, CO which broadcasts time on 2.5, 5, 10 and 30
mHZ. There is also one in Hawaii and sometimes you can hear both and
hear the difference. Canada also has one, which I forget the name of the
radio station and frequency.
--
Bud
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: ntpd question
Next: slack 13 OpenOffice