Bug 91927

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
the 
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

OR

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