On Tue, Nov 02, 2010 at 10:03:30PM +, David L. Mills wrote:
> I ran the same test here on four different machines with the
> expected results. These included Solaris on both SPARC and Intel
> machines, as well as two FreeBSD machines. I tested with and without
> the kernel, with initial offset
Hi,
We're having an issue with an NTPD whereby it's defaulting (or whatever the
correct terminology is) to the LOCAL clock, this is occurring when one of our
servers loses connectivity. We have 4 server's setup and the local clock is
also configured:
server 127.127.1.0 # local clock
fudge
Mirosalv,
Why didn't you tell me you are using Linux? All bets are off. You are on
your own.
The daemon clamps the adjtime() (sic) offset to 500 PPM, which is
consistent with ordinary Unix semantics. The Unix adjtime() syscall can
return the amount of time not amortized since the lasdt call
On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar wrote:
> On Tue, Nov 02, 2010 at 10:03:30PM +, David L. Mills wrote:
>> I ran the same test here on four different machines with the
>> expected results. These included Solaris on both SPARC and Intel
>> machines, as well as two FreeBSD machin
Dave,
I don't think that is right. The adjtime() call can be in principle
anything, accoridng to the Solaris and FreeBSD man pages, but the rate
of adjustment is fixed at 500 PPM in the Unix implementation. If the
Linux argument is limited to 500 microseconds, Linux is essentially
unusable wi
> From: Stephen Vaughan
> Date: Tue, 2 Nov 2010 23:13:47 -0700
> Sender: questions-bounces+oberman=es@lists.ntp.org
>
> Hi,
>
> We're having an issue with an NTPD whereby it's defaulting (or
> whatever the correct terminology is) to the LOCAL clock, this is
> occurring when one of our server
David L. Mills wrote:
> I don't think that is right. The adjtime() call can be in
> principle anything, accoridng to the Solaris and FreeBSD
> man pages, but the rate of adjustment is fixed at 500 PPM
> in the Unix implementation. If the Linux argument is
> limited to 500 microseconds, Linux i
David L. Mills wrote:
> > I don't think that is right. The adjtime() call can be in
> > principle anything, accoridng to the Solaris and FreeBSD
> > man pages, but the rate of adjustment is fixed at 500 PPM
> > in the Unix implementation. If the Linux argument is
> > limited to 500 microsecond
David L. Mills wrote:
I don't think that is right. The adjtime() call can be in principle
anything, accoridng to the Solaris and FreeBSD man pages, but the rate
of adjustment is fixed at 500 PPM in the Unix implementation. If the
Linux argument is limited to 500 microseconds, Linux is essentia
Hi Kevin,
I'm not sure why we have it in there, as you say it might have been part of the
default config in Redhat's EL ntp package. And yep, I don't understand why it's
reverting to the LOCAL clock and then just deciding to stick with it until we
restart ntp.
Cheers,
Stephen
-Original M
Stephen Vaughan wrote:
> I'm not sure why we have it in there, as you say it might
> have been part of the default config in Redhat's EL ntp
> package. And yep, I don't understand why it's reverting
> to the LOCAL clock and then just deciding to stick with
> it until we restart ntp.
>
>> server
Stephen Vaughan wrote:
Hi Kevin,
I'm not sure why we have it in there, as you say it might have been part of the
default config in Redhat's EL ntp package. And yep, I don't understand why it's
reverting to the LOCAL clock and then just deciding to stick with it until we
restart ntp.
Until
David,
In Mirsolav's test, the frequency was computed at 172 PPM, which is well
within the capabilities of the algorithm. On the other hand, even if the
intrinsic hardware frequency error is more than 500 PPM, the frequency
will be set to 500 PPM and the daemon will continue normally, but will
13 matches
Mail list logo
