FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 08-31-2012, 02:09 PM
Rainer Traut
 
Default C6: ntpd time reset +277092510.162464 s

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-31-2012, 02:19 PM
Tom Grace
 
Default C6: ntpd time reset +277092510.162464 s

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.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-31-2012, 02:31 PM
Woodchuck
 
Default C6: ntpd time reset +277092510.162464 s

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
--
If you see something, keep quiet.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-31-2012, 02:34 PM
Rainer Traut
 
Default C6: ntpd time reset +277092510.162464 s

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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-31-2012, 02:36 PM
Rainer Traut
 
Default C6: ntpd time reset +277092510.162464 s

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 ]


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 08-31-2012, 02:58 PM
Tom Grace
 
Default C6: ntpd time reset +277092510.162464 s

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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-03-2012, 07:41 AM
Rainer Traut
 
Default C6: ntpd time reset +277092510.162464 s

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=displayKC&externalId= 1006427

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

Rainer
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:46 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org