Hi All,
Thanks for your efforts trying to help me with this issue.
I understand that the reason for ntp to adjust with a sudden jumps may
be many. Some of them may be possible to prevent some others not. My
problem is that it MUST NOT JUMP.
I'm currently running a few tests, trying to verify
On Wed, Jul 13, 2011 at 04:49:37PM -0500, Hal Murray wrote:
The problem is that the adjustment takes to large steps, not that it
takes to long time.
ntpd will slew the clock at 500 PPM. You may be willing to wait a while
for a second or two, but it takes a long time if you have to
On Wed, Jul 13, 2011 at 10:51:46PM +0100, David Woolley wrote:
Hal Murray wrote:
OK. I asked since a timewarp of 200ms is a bit surprising for real HW,
but is something to be expected if you were running in a VM.
It's easy to get a time-warp of 200 ms on a DSL link. Just download
a huge
Bill wrote:
On 2011-07-12, Lars Ericsson laeatw...@gmail.com wrote:
Hi all,
I have been running the ntp client on a Linux platform for some time and
have not seen any problems.
I recently run into a strange behavior where our communication software
failed on some critical timeouts.
The following is an example from ntpd.log
14 Apr 07:22:25 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
14 Apr 07:22:25 ntpd[1048]: time reset +0.231004 s
14 Apr 07:23:35 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
14 Apr 07:39:33 ntpd[1048]: time reset +0.318457 s
14 Apr 07:39:33
Hi all,
I have been running the ntp client on a Linux platform for some time and
have not seen any problems.
I recently run into a strange behavior where our communication software
failed on some critical timeouts.
After some investigation we found out the the system time suddenly made a
jump
On 2011-07-12, Lars Ericsson laeatw...@gmail.com wrote:
Hi all,
I have been running the ntp client on a Linux platform for some time and
have not seen any problems.
I recently run into a strange behavior where our communication software
failed on some critical timeouts.
After some
Thanks for the reply.
I recently run into a strange behavior where our communication software
failed on some critical timeouts.
After some investigation we found out the the system time suddenly made a
jump with 200ms.
Yup. ntpd makes huge statements about the importance of keeping things
The problem is that the adjustment takes to large steps, not that it
takes to long time.
ntpd will slew the clock at 500 PPM. You may be willing to wait a while
for a second or two, but it takes a long time if you have to adjust
by several minutes or an hour. That may be OK for your setup,
Hal Murray wrote:
OK. I asked since a timewarp of 200ms is a bit surprising for real HW,
but is something to be expected if you were running in a VM.
It's easy to get a time-warp of 200 ms on a DSL link. Just download
a huge file, say a CD. The queuing delay on the input to the DSL
link
On Jul 13, 2011, at 2:44 PM, Hal Murray wrote:
OK. I asked since a timewarp of 200ms is a bit surprising for real HW,
but is something to be expected if you were running in a VM.
It's easy to get a time-warp of 200 ms on a DSL link. Just download
a huge file, say a CD. The queuing delay
The following is an example from ntpd.log
14 Apr 07:22:25 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
14 Apr 07:22:25 ntpd[1048]: time reset +0.231004 s
14 Apr 07:23:35 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
14 Apr 07:39:33 ntpd[1048]: time reset +0.318457 s
14 Apr 07:39:33
David Woolley david@ex.djwhome.demon.invalid wrote:
Hal Murray wrote:
OK. I asked since a timewarp of 200ms is a bit surprising for
real HW, but is something to be expected if you were running in a
VM.
It's easy to get a time-warp of 200 ms on a DSL link. Just
download a huge
13 matches
Mail list logo
