Jason Pyeron wrote, On 08/12/2010 09:27 AM:
>
>
>> -Original Message-
>> From: Todd Denniston
>> Sent: Thursday, August 12, 2010 9:07
>> Jason Pyeron wrote, On 08/12/2010 08:01 AM:
>> Assumption: the time servers that you are following
>> (192.168.1.6[57]) are:
>> a) each followin
Hi Jason,
On Aug 12, 2010, at 8:01 AM, Jason Pyeron wrote:
> Jul 28 21:42:34 devserver21 ntpd[3475]: frequency error -512 PPM
> exceeds
This shows that the system clock on devserver21 is driftin too fast
for NTP to compensate.
Possible causes could be an out-of-spec crystal on that machi
On 8/12/2010 9:03 PM, Les Mikesell wrote:
> ntpd always tries to move the clock fractional seconds at a time
msntp does that, too, if you give the -a flag. (You have to give either
-a or -r for it to change the system time at all.)
ntpdate also does this, as long as the delta is less than half
On Fri, 2010-08-13 at 09:47 -0500, Les Mikesell wrote:
> On 8/13/2010 4:06 PM, Jerry Franz wrote:
> > On 8/12/2010 8:03 PM, Les Mikesell wrote:
> Clients should never be 'balky' if you have a stable clock source -
> perhaps with the exception of some virtual machine situations or
> seriously ba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13/08/2010 23:06, Jerry Franz wrote:
> On 8/12/2010 8:03 PM, Les Mikesell wrote:
>> Warren Young wrote:
>>>
>>> The strategy I recommended is based on the fact that its worst case
>>> behavior (a small negative jump every hour) is not a problem for
On 8/13/2010 4:06 PM, Jerry Franz wrote:
> On 8/12/2010 8:03 PM, Les Mikesell wrote:
>> Warren Young wrote:
>>>
>>> The strategy I recommended is based on the fact that its worst case
>>> behavior (a small negative jump every hour) is not a problem for me. If
>>> it is a problem for your applicatio
On 8/12/2010 8:03 PM, Les Mikesell wrote:
> Warren Young wrote:
>>
>> The strategy I recommended is based on the fact that its worst case
>> behavior (a small negative jump every hour) is not a problem for me. If
>> it is a problem for your application, you need a different design.
>
> It's a bad
Warren Young wrote:
>
> The strategy I recommended is based on the fact that its worst case
> behavior (a small negative jump every hour) is not a problem for me. If
> it is a problem for your application, you need a different design.
It's a bad idea in the general case. If you have scheduled
Jason Pyeron wrote:
>
>
>> -Original Message-
>> From: centos-boun...@centos.org
>> [mailto:centos-boun...@centos.org] On Behalf Of Warren Young
>> Sent: Thursday, August 12, 2010 17:41
>> To: CentOS mailing list
>> Subject: Re: [CentOS] Date
On 8/12/2010 4:15 PM, John R Pierce wrote:
>On 08/12/10 2:51 PM, Warren Young wrote:
>>
>> Only one server on a given LAN should be running ntpd. It's overkill
>> for every machine to keep themselves synced with such a complex and
>> fussy server. All the others should just call ntpdate or ms
On 08/12/10 2:51 PM, Warren Young wrote:
>
> Only one server on a given LAN should be running ntpd. It's overkill
> for every machine to keep themselves synced with such a complex and
> fussy server. All the others should just call ntpdate or msntp every
> hour or so as a cron job to keep their
On 8/12/2010 3:43 PM, Jason Pyeron wrote:
>
> Okay, I only have one timeserver,
I meant that your on-site time server should be relying on only one
other outside time server, one stratum up.
> but the ntp clients cowardly refuse to use
> less than 3.
Only one server on a given LAN should be run
> -Original Message-
> From: centos-boun...@centos.org
> [mailto:centos-boun...@centos.org] On Behalf Of Warren Young
> Sent: Thursday, August 12, 2010 17:41
> To: CentOS mailing list
> Subject: Re: [CentOS] Date drift and ntpd
>
> On 8/12/2010 5:07 AM, Jason
On 8/12/2010 5:07 AM, Jason Pyeron wrote:
>
> [r...@devserver21 ~]# cat /etc/ntp.conf | grep -v ^# | grep -v ^$
> restrict default nomodify notrap noquery
> restrict 127.0.0.1
> server 192.168.1.67
> server 192.168.1.66
> server 192.168.1.65
Some HOWTOs tell you that more time servers is better, o
> -Original Message-
> From: Todd Denniston
> Sent: Thursday, August 12, 2010 9:07
> Jason Pyeron wrote, On 08/12/2010 08:01 AM:
> >> -Original Message-
> >> From: Simon Billis
> >> Sent: Thursday, August 12, 2010 7:36
> >>
> >> Jason Pyeron sent a missive on 2010-08-12:
> >>
> >
Jason Pyeron wrote, On 08/12/2010 08:01 AM:
>
>
>> -Original Message-
>> From: centos-boun...@centos.org
>> [mailto:centos-boun...@centos.org] On Behalf Of Simon Billis
>> Sent: Thursday, August 12, 2010 7:36
>> To: 'CentOS mailing list'
> -Original Message-
> From: centos-boun...@centos.org
> [mailto:centos-boun...@centos.org] On Behalf Of Simon Billis
> Sent: Thursday, August 12, 2010 8:14
> To: 'CentOS mailing list'
> Subject: Re: [CentOS] Date drift and ntpd
>
> Hi,
>
> &g
Hi,
> > Jason Pyeron sent a missive on 2010-08-12:
> >
> > > We have a local time server and all of our machines are
> > pointed at it
> > > for the time.
> > >
> > > How can the clock drift by a day and a half?
> >
/SNIP
> > It is unlikely that the machine in question drifted forward
> > in time
Hi,
> > Jason Pyeron sent a missive on 2010-08-12:
> >
> > > We have a local time server and all of our machines are
> > pointed at it
> > > for the time.
> > >
> > > How can the clock drift by a day and a half?
> > >
> > > [r...@devserver21 ~]# date
> > > Fri Aug 13 14:43:29 EDT 2010
> > > [r...@
> -Original Message-
> From: centos-boun...@centos.org
> [mailto:centos-boun...@centos.org] On Behalf Of Simon Billis
> Sent: Thursday, August 12, 2010 7:36
> To: 'CentOS mailing list'
> Subject: Re: [CentOS] Date drift and ntpd
>
> Jason Pyeron sent
Jason Pyeron sent a missive on 2010-08-12:
> We have a local time server and all of our machines are pointed at it
> for the time.
>
> How can the clock drift by a day and a half?
>
> [r...@devserver21 ~]# date
> Fri Aug 13 14:43:29 EDT 2010
> [r...@devserver21 ~]# rdate -s 192.168.1.67
> [r...@
21 matches
Mail list logo