On 2013-02-25, Trevor Woerner <twoer...@gmail.com> wrote: > Hi everyone, > > I have been getting the following pattern show up in my log files and > I'm hoping to better understand why and perhaps figure out how to > improve the situation. > > I have two machines. One of which, the server, is syncing to an > upstream NTP server over one ethernet interface and acts as the > server to another, client, machine over a separate ethernet interface. > The two machines are connected via their own private switch and > have virtually no traffic between them, other than the NTP messages. > > The client: > - is running NTP version 4.2.4p4 > - has an IP address of 148.198.225.200 > - runs ntp with only the '-g' option > - it's /etc/ntp.conf file looks like > > driftfile /etc/ntp.drift > server 148.198.225.221 minpoll 4 maxpoll 5 > > When NTPd is started up on the client, it will initially set its time with: > > # ntpd -n -q -g
Why? ntpd will step the clock if it decides that the time is out by .128 sec. It will die if the time is out by something like 1000 sec which is why the -g is there, so that on startup the system can reset the clock by a large amount without dying. But that is one time step. If it ever goes out by that amount again ntpd will die. > > and then run ntpd as: > > # ntpd -g > > The server's IP address is 148.198.225.221 and is running ntpd 4.2.0a. Why are you running such an ancient version of ntpd? > .... > > But ignoring that for the moment, why does ntpd wait until it is out by ~2 > seconds before making a change? Is it possible to have it make the > change sooner (say, when it's out by only 1/4 second)? > > If I look at all the time resets: > > 2013-02-21T23:44:43.049+05:00 ntpd[4396]: time reset -2.179424 s > 2013-02-22T01:19:43.289+05:00 ntpd[4396]: time reset +0.237872 s > 2013-02-22T10:30:49.047+05:00 ntpd[4396]: time reset -0.242646 s > 2013-02-22T13:58:47.261+05:00 ntpd[4396]: time reset -1.785796 s > 2013-02-22T14:48:28.015+05:00 ntpd[4396]: time reset -0.245943 s > 2013-02-22T19:17:30.870+05:00 ntpd[4396]: time reset -2.147083 s > 2013-02-23T11:32:55.635+05:00 ntpd[4396]: time reset -0.236013 s > 2013-02-23T13:22:50.772+05:00 ntpd[4396]: time reset +2.139825 s > 2013-02-23T16:01:20.626+05:00 ntpd[4396]: time reset -2.147514 s > 2013-02-24T12:15:48.772+05:00 ntpd[4396]: time reset +2.148165 s > 2013-02-24T12:49:12.921+05:00 ntpd[4396]: time reset +2.149475 s > 2013-02-24T22:41:09.775+05:00 ntpd[4396]: time reset -2.145805 s > 2013-02-25T10:27:47.921+05:00 ntpd[4396]: time reset +2.145463 s That is completely nuts and indicates something is seriously seriously seriously wrong. It should never reset the time, except on startup. Ever resetting the time indicates serious problems. Perhaps some program is fighting with ntpd and resetting the clock itself for some reason. Look in the measurements log file to see what the offsets are that your system is getting, and to see what the roundtrip delays are. > > Eight out of thirteen have a reset that is amazingly close to 2.14 seconds. Even one reset is too many. > It's almost as if it's waiting until it is out by 2.14 seconds before > performing > the reset. But in addition to that, the sign of the change keeps flipping. > First > it's minus 2 seconds, then plus 2 seconds, then minus for a couple, the plus > for a couple. It just doesn't seem as if the client is tracking the > server's time > very well. Agreed, and you need to figure out why. On your system, the two times should track withing microseconds of eachother always. > > Running ntpq on the client (today) gives: > > remote refid st t when poll reach delay offset > jitter >============================================================================== > *148.198.225.221 148.198.40.161 4 u 7 32 377 0.175 -0.540 > 1.213 > > 148.198.40.161 is the upstream server of the "server" machine > (148.198.225.221) > in this configuration. > > Any suggestions? Can I provide any more information? Upgrade your ntpd. Try again. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
