time will be synchronized but will be corrected through time reset:
uwl@dingo:~> tail -6 /var/log/ntp
5 Dec 21:14:43 ntpd[2453]: synchronized to 192.168.88.3, stratum 2
5 Dec 21:14:43 ntpd[2453]: time reset +0.432337 s
5 Dec 21:14:43 ntpd[2453]: kernel time sync status change 0001
5 Dec 21:26:04 ntpd[2453]: synchronized to 192.168.88.3, stratum 2
5 Dec 21:46:31 ntpd[2453]: time reset +0.284307 s
5 Dec 21:47:34 ntpd[2453]: synchronized to 192.168.88.3, stratum 2
uwl@dingo:~> cat /var/lib/ntp/drift/ntp.drift
-235.075
As you can see ntp.drift is not very high. Not -500 or so, but the time will be reseted permanently.
The /etc/adjtime contains only 0.0 0 0.0 … I’m using ReiserFS for /home, but I umounted it and it wasn’t help. I believe, it may be a hardware problem. I booted this PC with opensolaris live CD and configured xntpd there. The clock stays synchronized, will not be reseted and after 2 hours the ntp.drift contains something like 10.678. What could be done to correct this time jumping behavior on Linux?
Something about this PC and installation:
uwl@dingo:~> cat /proc/cpuinfo | grep name
model name : Intel(R) Pentium(R) 4 CPU 2.60GHz
uwl@dingo:~> cat /etc/SuSE-release
openSUSE 11.2 (i586)
VERSION = 11.2
uwl@dingo:~> uname -a
Linux dingo 2.6.31.5-0.1-default #1 SMP 2009-10-26 15:49:03 +0100 i686 i686 i386 GNU/Linux
uwl@dingo:~> rpm -q ntp
ntp-4.2.4p7-6.3.i586
uwl@dingo:~> sudo cat /etc/ntp.conf | egrep -v '(^#|^$)'
server roo iburst
driftfile /var/lib/ntp/drift/ntp.drift # path for drift file
logfile /var/log/ntp # alternate log file
statsdir /var/log/ntpstat/ # directory for statistics files
statistics loopstats peerstats clockstats
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
keys /etc/ntp.keys # path for keys file
trustedkey 1 # define trusted keys
requestkey 1 # key (7) for accessing server variables
I don’t see what the problem is, my host has uptime, 19:20 up 4 days
Your “time reset” log items get gradually smaller. Use the peer offsets to see if you are synchronised, so long as they are stable you ought to be fine.
fir:/var/log # echo peers |ntpdc
peers
remote local st poll reach delay offset disp
tail /var/log/ntp.log
6 Dec 07:29:15 ntpd[25337]: synchronized to 80.5.182.144, stratum 2
6 Dec 07:31:49 ntpd[25337]: synchronized to 212.13.195.14, stratum 2
6 Dec 11:54:39 ntpd[25337]: time reset -0.223165 s
6 Dec 11:55:34 ntpd[25337]: synchronized to 80.5.182.144, stratum 2
6 Dec 11:58:55 ntpd[25337]: synchronized to 212.13.195.14, stratum 2
6 Dec 13:57:24 ntpd[25337]: time reset -0.193673 s
6 Dec 13:57:24 ntpd[25337]: kernel time sync status change 4001
6 Dec 13:58:00 ntpd[25337]: synchronized to 212.13.195.14, stratum 2
6 Dec 13:58:00 ntpd[25337]: kernel time sync status change 0001
6 Dec 16:14:59 ntpd[25337]: synchronized to 80.5.182.144, stratum 2
6 Dec 17:19:29 ntpd[25337]: time reset -0.131629 s
6 Dec 17:19:52 ntpd[25337]: synchronized to 80.5.182.144, stratum 2
6 Dec 18:23:57 ntpd[25337]: synchronized to 212.13.195.14, stratum 2
Your timer is too quick and will not be slow enough to avoid resets. My timer is too slow and can’t be quick enough to do the same. Can you please show the /var/lib/ntp/drift/ntp.drift and /etc/adjtime?
I’m behind a firewall and can’t configure more than one ntp server. Uptime is not a problem here. Opensolaris achieves synch in several minuets and stays synchronized 2 hours long without time reset on the same hardware. (I didn’t tested it longer, but I think, it’s long enough to say it’s OS timer or ntpd). I have several Unix boxes in this network and only this one has this problem.
I found some advises, how to solve similar problems: delete adjtime, ntp.drift, reboot an so on, but it didn’t help. /etc/adjtime looks like this:
uwl@dingo:~> cat /etc/adjtime
0.0 0 0.0
0
UTC
yes, my HW Clock is set to UTC. And ntp.drift will be generated with the same -250 - -220 in it.
Can you make the following and post the result please:
uwl@dingo:~> while true; do /usr/sbin/ntpq -pn | egrep -v "(remote|=====)"; sleep 120; done
*192.168.88.3 195.145.119.188 2 u 23 64 377 0.239 21.488 27.178
*192.168.88.3 195.145.119.188 2 u 15 64 377 0.303 44.123 21.758
*192.168.88.3 195.145.119.188 2 u 6 64 377 0.303 44.123 28.721
*192.168.88.3 195.145.119.188 2 u 63 64 377 0.326 81.228 15.442
*192.168.88.3 195.145.119.188 2 u 53 64 377 0.257 94.656 16.819
*192.168.88.3 195.145.119.188 2 u 42 64 377 0.223 110.196 23.101
*192.168.88.3 195.145.119.188 2 u 33 128 377 0.223 110.196 21.550
*192.168.88.3 195.145.119.188 2 u 25 128 377 0.223 110.196 29.504
*192.168.88.3 195.145.119.188 2 u 15 128 377 0.223 110.196 43.927
*192.168.88.3 195.145.119.188 2 u 6 128 377 0.223 110.196 62.949
*192.168.88.3 195.145.119.188 2 u 126 128 377 0.223 110.196 62.949
*192.168.88.3 195.145.119.188 2 u 118 128 377 0.223 110.196 84.410
*192.168.88.3 195.145.119.188 2 u 108 128 377 0.223 110.196 107.898
*192.168.88.3 195.145.119.188 2 u 99 128 377 0.257 125.916 119.029
*192.168.88.3 195.145.119.188 2 u 91 128 377 0.271 316.284 104.598
*192.168.88.3 195.145.119.188 2 u 21 64 1 0.226 6.518 0.410
Yeh, that’s something common with ntp weirdness, to get rid of adjtime etc Then restart it all.
Can you file a bug report on this? The time hasn’t been inaccurate enough for me to notice, and I have lots of ongoing bugs filed already. You can reference this thread in the bugzilla to help you explain things, they stick around.
So today I see my sync is surprisingly far out, after a reboot last night :
echo peers |ntpdc
peers
remote local st poll reach delay offset disp
Quite a shockingly innacurate clock, reminds me of Slowaris 2.4 and 2.5!
Good spot of yours on the time, it’s so long since I had an NTP problem that needed any attention (like 1992 DEC Ultrix & compile errors with gcc in 1994 or so SunOS/Slowaris2!).
Created an attachment (id=329859) [details]
graph of loopstats w/ 4.2.4p7-6.3 and 4.2.4p6-2.2.1
graph of loopstats data with buggy 4.2.4p7-6.3 (left) and reversion to
4.2.4p6-2.2.1 (right). Note clipping of offset, unstable frequency offset and
jitter with 4.2.4p7-6.3, return to stable operation after reversion to
4.2.4p6-2.2.1.
