Bug 91927 - LTC2938-ntp-4.1.0b-2.AS21.4.i386.rpm has trouble accurately setting time
Summary: LTC2938-ntp-4.1.0b-2.AS21.4.i386.rpm has trouble accurately setting time
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: ntp
Version: 2.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Depends On:
Blocks: 87937
TreeView+ depends on / blocked
Reported: 2003-05-29 21:44 UTC by IBM Bug Proxy
Modified: 2007-11-30 22:06 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2003-12-19 14:49:58 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2003:254 normal SHIPPED_LIVE Updated ntp package fixes several bugs 2003-12-19 05:00:00 UTC

Description IBM Bug Proxy 2003-05-29 21:44:53 UTC
Hardware Environment: 
IBM x440 
Software Environment: 
o RHAS AS2.1 running the 2.4.9e16-summit kernel 
o Included NTP package: ntp-4.1.0b-2.AS21.4.i386.rpm 
Steps to Reproduce: 
1. Run ntpdate -ub <timesrever> multiple times 
Actual Results: 
o Every time we try to set the clock, we are off on average .5seconds.  
Expected Results: 
o Clock should be set to ~10ms accuracy 
Additional Information: 
The ntp-4.1.0b-2.AS21.r.i386.rpm package uses stime() rather then settimeofday() 
when setting the time. This gives it only second accuracy, as stime() does not take 
a microsecond argument.   This can be seen when setting the clock w/ "ntpdate 
-qb" or when ntpd is running and ossolates setting the time back and fourth over
desired time value.  This causes ntpd to take a very long time to converge onto the 
proper time.  
ntp-4.1.1 uses settimeofday() and can accurately set time to within ~10ms. In one 
case we had a customer install ntp-4.1.1 and the NTP related problems they were 
seeing disappeared.  
It is desired that RHAS's ntp package be updated to ntp-4.1.1. 
* As a side note, the ntp-4.1.1-1.i386.rpm package from RH7.3 includes the patch 
"ntp-4.1.0b-rc1-droproot.patch" which has a minor bug.  It accidentally adds an 
extra ":" to the ntp_options string, which causes the argument parser to think
that the 
-x option requires an argument (when it actually does not). Hopefully this issue 
would be resolved as well when the RHAS ntp packages is updated to 4.1.1.

------- Additional Comment #2 From john stultz 2003-05-28 22:35 -------

Created an attachment (id=912)
NTP adjtime limit patch

Additionally it has been found that the ntp-4.1.1-1.i386.rpm package mentioned
above has problems with slewing the time using the -x option. If the -x option
is being used and the clock is manually skewed greater then .5 seconds, it is
possible ntp will be unable to correct the skew. This is because ntp will call
adjtimex() with offset values greater then .5 seconds. Since the kernel ignores
any requests to adjtimex() with offsets greater then .5 seconds, the adjtimex
call fails and time is not adjusted. The attached patch (found in the
ntp-4.1.0b-2.AS21.4.src.rpm source package) limits ntp's calls to adjtimex() so
it never requests adjustments so large that the kernel will ignore. 

It is requested that this patch also be applied to the version of ntp-4.1.1
that is requested to be updated for RHAS. 

------- Additional Comment #3 From john stultz 2003-05-28 22:41 -------

Additionally, it might be easier for RedHat to stick w/ the 4.1.0 version of ntp
as long 
as they are able to build it such that it uses settimeofday() rather then
stime().  This 
would likely solve our problem in a simpler manner, as the 
ntp-4.1.0b-2.AS21.4.src.rpm package already has fixes for both the "adjtime limit" 
and "-x requires an option" bugs.  

We would like to get Red Hat to release a new version of the NTP RPM for RHAS
2.1 that addresses the issues listed in this bug. 

1) Release NTP version 4.1.1 that:
   a) uses settimeofday() instead of stime().
   b) fixes the -x error introduced with ntp-4.1.0b-rc1-droproot.patch
   c) fixes the -x argument time SLEW problem


2) Release NTP version 4.1.0b-2 that:
   a) uses settimeofday() instead of stime().

Comment 1 Harald Hoyer 2003-05-30 12:41:41 UTC
have you tried recent versions of ntp?

does this fit your needs? Should have all the fixes you need.

a quick look with strace showed the use of 
settimeofday({1054298490, 568184}, NULL) = 0

Comment 2 Chris McDermott 2003-06-04 02:20:14 UTC
John Stultz built and tested the ntp-4.1.2-0.rc1.2.src.rpm package. Everything
looked good. When can we expect to see this package released for RHAS 2.1?

Comment 3 Matt Wilson 2003-06-23 16:04:38 UTC
This is a bug against RHEL 2.1?  If so, the Product should be Red Hat Enterprise
Linux, Version 2.1

Comment 4 IBM Bug Proxy 2003-06-23 22:07:37 UTC
------ Additional Comments From jstultz@us.ibm.com(prefers email via johnstul@us.ibm.com)  2003-20-06 18:13 -------
Since we've heard nothign from redhat, we would like to see this resolved in future versions


Comment 5 IBM Bug Proxy 2003-08-20 19:25:08 UTC
------ Additional Comments From khoa@us.ibm.com  2003-20-08 10:37 -------
Fix is already available in rawhide - thanks! 
We would like  Red Hat to include the fix into RHAS 2.1., (QU3) 

Comment 6 Harald Hoyer 2003-08-21 10:09:12 UTC
it is already in the errata queue...
see bug #84264

Comment 7 Florian La Roche 2003-09-22 16:17:07 UTC
I set this to modified since the new rpm is built into errata-candidate.


Florian La Roche

Comment 8 john stultz 2003-11-19 02:43:21 UTC
The package pointed to in comment #1 has disappeared (earlier found 
on by replacing wallace w/ ftp.redhat.com). Where can now we find 
the new errata-candidate rpm/srpm?  

Comment 9 John Flanagan 2003-12-19 14:49:58 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


Comment 10 IBM Bug Proxy 2004-02-18 00:59:20 UTC
----- Additional Comments From jstultz@us.ibm.com(prefers email via johnstul@us.ibm.com)  2004-02-17 19:59 -------
This bug has been addressed by the RH errata: 
The RH bug #91927 has been closed for some time. So I'm closing this as well. 

Note You need to log in before you can comment on or make changes to this bug.