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

Unruh unruh-spam at physics.ubc.ca
Wed Apr 9 18:23:03 UTC 2008

"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>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

>Something is VERY wrong there.  It looks as if NTPD is making a massive 
>correction every fifteen minutes or so!

>If you reboot without running NTPD, and set the time manually, how badly 
>does it drift?  If it gains or loses more than something like 43 seconds 
>per day, NTPD will not work until you get your hardware fixed.  Gaining 
>or losing 1 or 2 seconds per day without NTPD is the expected level of 
>performance for a typical computer clock.  (You get the finest hardware 
>that $2 US can buy!)

Well, no. 1 or 2 sec is 10-20PPM which is on the good side. 43 sec per day
is like 500PPM which is definitely on the high side. 5-10sec per day is
more typical. Note that chrony(on linux) will fix 43s/day. (It will use the fast
slew-- ie changing the tick size-- as well as the slow slew.) ntp as a
design decision decided that 500PPM was the max it would ever do.  NOt that I
advise a computer with 500PPM freq error. something is wrong and is liable
to be wrong in more places than just the clock. 

More information about the questions mailing list