C6: Ntpd Time Reset +277092510.162464 S

Home » CentOS » C6: Ntpd Time Reset +277092510.162464 S
CentOS 6 Comments

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

6 thoughts on - C6: Ntpd Time Reset +277092510.162464 S

  • 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.

  • 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:19, schrieb Tom Grace:

    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.

  • Am 31.08.2012 16:31, schrieb Woodchuck:

    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 ]

  • 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.

    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:

    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=displayKC&externalId06427

    Means, no time sync using vmware-tools, just ntpd with no local timesource.

    Rainer

LEAVE A COMMENT