[ntp:questions] Time slew doesn't seem to work

Andy andy.heltenNOSPAM at dot21rts.com
Wed Apr 9 14:40:59 UTC 2008

jkvbe wrote:
> Hi,
> I've started ntpd with the -x option and defined at run-time (using ntpdc) 3
> servers. The client machine has an offset of +/- 2s with the ntp servers.
> In the NTP log file I find the following statements (extracted out of a
> total of 98):
> 9 Apr 07:46:13 ntpd[19257]: time slew 1.781571 s
> 9 Apr 08:01:16 ntpd[19257]: time slew 1.781200 s
> 9 Apr 08:17:21 ntpd[19257]: time slew 1.781085 s
> 9 Apr 08:32:33 ntpd[19257]: time slew 1.781807 s
> 9 Apr 08:48:37 ntpd[19257]: time slew 1.782273 s
> 9 Apr 09:04:38 ntpd[19257]: time slew 1.781004 s
> 9 Apr 09:19:42 ntpd[19257]: time slew 1.781344 s
> 9 Apr 09:34:46 ntpd[19257]: time slew 1.780407 s
> 9 Apr 09:49:50 ntpd[19257]: time slew 1.778824 s
> The times don't seem to converge.
> When I shut down the ntp daemon and try to slew the time using ntpdate with
> the -B option it does work. The time difference with the ntp servers
> gradually declines.
> We use Suse SLES10 (kernel version: 2.6.16).
> Does anybody have an idea on what's going wrong?
> Thanks,
> Jan
Two things:
(1)  Try running with time stepping enabled on that system (i.e. don't
use the '-x' flag) to see how well the system keeps time.  What kind of
offset do you have after 1 or 2 hours of operation?
(2)  Check your drift value when running with time stepping disabled
(also check it with time stepping enabled).  You can do this with 'ntpq
-crv' where 'frequency' is the drift value or you can dump the drift
file (probably /var/lib/ntp/drift).  Note that the drift file is only
updated once every hour or so.

I encountered a problem on linux 2.6.18 in which disabling of time
stepping (using either '-x' or 'tinker step 0') caused the drift value
to run at or near +/-500ppm and subsequently caused a time offset of
several milliseconds.  If I allow time steps on that same system, it
runs with a drift <100ppm and maintains an offset <1ms.  I am using an
IRIG time source, so I expect high accuracy.  In my system, a time step
is never needed (i.e. the offset never grows larger than 128ms),
regardless of whether time stepping is enabled or disabled.  This
doesn't change the fact that it runs like crap with time stepping disabled.


More information about the questions mailing list