[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
>(hardware/software combination). 
>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 mailing list