[EMAIL PROTECTED] wrote:
I've googled for this problem and generally it seems to be caused by a
networking problem, although I can't see anything that would indicate
that. I'm running ubuntu , with only a couple of changes from the
default configuration... uncommenting the pool NTP server, and adding a
local ISP ntp server. I've been playing with this all afternoon, and
I've come against a dead end. I'll probably realise I've done something
stupid as soon as I send this off :-)
to start off:
# ntptrace
localhost.localdomain: stratum 16, offset -0.025048, synch distance
0.012000
Stratum 16 says you are not synchronized.
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*fortitude.route 82.96.64.2 2 u 56 64 377 10.235 -105.53
23.437
The "*" beginning the above line says that fortitude.route.??? has been
selected as the synchronization source. The offset of -105.53
milliseconds says that you are not yet close to being synchronized.
+fiordland.ubunt 193.79.237.14 2 u 60 64 377 11.248 -95.855
24.182
The above line says that fiolrdland.ubunt??? is a member of the
selection set. The offset of -95.855 milliseconds is more or less in
agreement with fortitude.route.??? So say that your local clock is
about 100 milliseconds off.
xclock-b.develoo 192.12.19.20 2 u 53 64 377 564.283 -348.56
47.912
LOCAL(0) LOCAL(0) 13 l 55 64 377 0.000 0.000
0.002
How long has this been running? Did you start ntpd with the -g option?
That would tell it to set the clock on startup. The maximum rate at
which ntpd can slew the clock is 500 PPM or 0.5 milliseconds per second.
At that rate, a 100 millisecond offset will be corrected in about 200
seconds. Ntpd will probably overshoot and correct the other way,
overshoot again and correct. Eventually, it will pull in to something
resembling tight synchronization. If you are cold starting ntpd, it can
take quite a while to tweak all the knobs to their proper settings.
clock-b.develoo.??? I assume is the server assigned by the pool. It is
a poor choice for your location. Note the delay of 564.283
milliseconds! The offset is ridiculous and the jitter is high! It's
not the server, it's the network between your site and clock-b. The "x"
at the beginning of the line says that ntpd has pronounced this server
"insane"! Again, it's the network not the server.
You can ask for a pool server by region; e.g. US, Europe, etc. An
appropriate choice of region should get you a server better suited to
your location. I don't use pool servers myself and can't tell you
exactly how so you'll need to see the documentation to find the
available regions and the correct syntax. In selecting non-pool
servers, look for servers close to you in network space. Such servers
will necessarily be close to you physically (0-300 miles) but the
converse is not necessarily true.
You should use the "iburst" keyword in all of your server statements for
faster startup. Iburst gets you the necessary information to start
synchronizing your clock in something like 20 seconds versus a little
more than five minutes without.
Finally, you have either too many or too few servers. With three
configured and one declared insane you wind up with two, the worst
possible configuration. With one server ntpd will synchronize with it,
right or wrong. With two, ntpd has no way to tell which one is more
nearly correct or if both are hopelessly wrong. Three servers
degenerate too easily to the two server case. With four well chosen
servers, your system should be a lot happier.
<big snip>
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
