Hi,
I'm in the middle of migrating our oracle servers to RHEL and C6; while testing ntpd I'm seeing time resets.
I see in sysconfig/ntpd the option g is set which means huge offset is one time ignored. But my understanding of ntpd is, it slows or accelerated kernel clock but does not make huge jumps...
Is this really expected behaviour?
The file step-tickers is empty, ntp.conf is minimal:
driftfile /var/lib/ntp/drift restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 10.0.1.27
/var/log/messages:
Nov 20 12:48:06 aitcsdb002 ntpd[5816]: ntpd 4.2.4p8@1.1612-o Thu May 13 14:38:25 UTC 2010 (1) Nov 20 12:48:06 aitcsdb002 ntpd[5817]: precision = 0.065 usec Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #1 wildcard, ::#123 Disabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #2 lo, ::1#123 Enabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #3 eth1, fe80::20c:29ff:fef1:3fee#123 Enabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #4 eth0, fe80::20c:29ff:fef1:3fe4#123 Enabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #5 lo, 127.0.0.1#123 Enabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #6 eth0, 10.0.4.16#123 Enabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on interface #7 eth1, 10.0.5.16#123 Enabled Nov 20 12:48:06 aitcsdb002 ntpd[5817]: Listening on routing socket on fd #24 for interface updates Nov 20 12:48:06 aitcsdb002 ntpd[5817]: kernel time sync status 2040 Aug 31 16:00:51 aitcsdb002 ntpd[5817]: synchronized to 10.0.1.27, stratum 3 Aug 31 16:00:51 aitcsdb002 ntpd[5817]: time reset +277092510.162464 s
Thx
On 31/08/12 15:09, Rainer Traut wrote:
I see in sysconfig/ntpd the option g is set which means huge offset is one time ignored. But my understanding of ntpd is, it slows or accelerated kernel clock but does not make huge jumps...
With the options you mentioned, NTPd will make a big jump once at startup.
If the clock is wrong by (if I remember correctly) about 30 mins it will take so long to drift back to being correct that NTPd gives up.
Am 31.08.2012 16:19, schrieb Tom Grace:
On 31/08/12 15:09, Rainer Traut wrote:
I see in sysconfig/ntpd the option g is set which means huge offset is one time ignored. But my understanding of ntpd is, it slows or accelerated kernel clock but does not make huge jumps...
With the options you mentioned, NTPd will make a big jump once at startup.
If the clock is wrong by (if I remember correctly) about 30 mins it will take so long to drift back to being correct that NTPd gives up.
Hmm, no it still does time resets in my tests iIf I set the clock -27s of timesource. This happens: Aug 31 16:30:14 aitcsdb002 ntpd[6062]: time reset +27.006389 s
Note, this is a vm under ESXi5 but the VMWare time sync is completely disabled.
On 31/08/12 15:34, Rainer Traut wrote:
Am 31.08.2012 16:19, schrieb Tom Grace:
If the clock is wrong by (if I remember correctly) about 30 mins it will take so long to drift back to being correct that NTPd gives up.
Hmm, no it still does time resets in my tests iIf I set the clock -27s of timesource. This happens: Aug 31 16:30:14 aitcsdb002 ntpd[6062]: time reset +27.006389 s
Ah, it turns out I was wrong about the 30 mins thing, that relates to some other issue with NTP giving up and quitting if the clock is drifting around too much.
From the docs (paraphrased a bit):
Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. If the step threshold is set to zero, all offsets are stepped, regardless of value.
Note: Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize.
Am 31.08.2012 16:58, schrieb Tom Grace:
On 31/08/12 15:34, Rainer Traut wrote:
Am 31.08.2012 16:19, schrieb Tom Grace:
If the clock is wrong by (if I remember correctly) about 30 mins it will take so long to drift back to being correct that NTPd gives up.
Hmm, no it still does time resets in my tests iIf I set the clock -27s of timesource. This happens: Aug 31 16:30:14 aitcsdb002 ntpd[6062]: time reset +27.006389 s
Ah, it turns out I was wrong about the 30 mins thing, that relates to some other issue with NTP giving up and quitting if the clock is drifting around too much.
Thanks Tom and Dave for your answers.
I double checked with real hardware - there it works - so this looks to me like a bug in ESXi5 running RHEL6/C6 and ntpd.
We are running latest VMware ESXi5 patch 768111 and latest RHEL/CentOS. I followed VMware's best practices closely:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...
Means, no time sync using vmware-tools, just ntpd with no local timesource.
Rainer
On Fri, Aug 31, 2012 at 04:09:54PM +0200, Rainer Traut wrote:
Hi,
I'm in the middle of migrating our oracle servers to RHEL and C6; while testing ntpd I'm seeing time resets.
Well, the delta-T is something like 8.8 ~years~, so I'd suggest first checking the BIOS clock in the host in question, and if it is always so far from truth, replace its little battery.
Dave
Am 31.08.2012 16:31, schrieb Woodchuck:
On Fri, Aug 31, 2012 at 04:09:54PM +0200, Rainer Traut wrote:
Hi,
I'm in the middle of migrating our oracle servers to RHEL and C6; while testing ntpd I'm seeing time resets.
Well, the delta-T is something like 8.8 ~years~, so I'd suggest first checking the BIOS clock in the host in question, and if it is always so far from truth, replace its little battery.
This was just for testing, it's a vm under ESXi 5. I'm doing this: [root@aitcsdb002 ~]# /etc/init.d/ntpd stop ntpd beenden: [ OK ] [root@aitcsdb002 ~]# date --set="-27 seconds" Fr 31. Aug 16:35:15 CEST 2012 [root@aitcsdb002 ~]# /etc/init.d/ntpd start ntpd starten: [ OK ]
-
Rainer Traut -
Tom Grace -
Woodchuck