[ntp:questions] Re: Ntp-4.1.2: tinker step 0; always slew andkernel time discipline
Richard B. Gilbert
rgilbert88 at comcast.net
Fri Feb 18 19:29:49 UTC 2005
Nikolaev, Sergey wrote:
>Not running NTP is not an option. At least on one type of Sun systems we
>had this problem where a system clock
>would jump 2 seconds. After long efforts of talking to Sun support, this
>explanation was given by Sun.
>The system has 2 clocks: TOD (hardware) and the system clock
>If the 2 clocks drift to 2 seconds apart, the system clock is set to the
>time of the TOD.
>Actually, according to my tests, this correction is done over span of 30
>seconds at a rate of 70ms/s.
>This "jump" was freaking out one of our time sensitive applications.
>When the system clock is set by software (i.e. NTP), TOD is set too, so
>they are synced. So, if NTP is running,
>it adjusts the system clock relatively frequently, reseting both the
>system clock and TOD, so they never have
>enough time to drift apart 2 seconds and NTP does not even need to react
>to the 2 second jump.
>The only reason we are considering the option of always slewing is
>because we had the problem where NTP itself
>would introduce a jump, step the clock, because of perceived ofset
>greater than 128ms due asymmetric network delays.
>Our applications usually disconnect clients in this case and this is
>To avoid this we have been thinking about forcing NTP to always slew.
>But it looks like this approach has drawbacks too.
Have you considered:
1. Getting a better network connection to reduce or eliminate
asymmetric delays, or
2. Getting a hardware reference clock; e.g. a GPS timing receiver?
It seems to me that either option would be likely to improve your situation.
More information about the questions