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().
have you tried recent versions of ntp? e.g. ftp://wallace/pub/redhat/linux/rawhide/SRPMS/SRPMS/ntp-4.1.2-0.rc1.2.src.rpm 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
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?
This is a bug against RHEL 2.1? If so, the Product should be Red Hat Enterprise Linux, Version 2.1
------ Additional Comments From jstultz.com(prefers email via johnstul.com) 2003-20-06 18:13 ------- Since we've heard nothign from redhat, we would like to see this resolved in future versions
------ Additional Comments From khoa.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)
it is already in the errata queue... see bug #84264
I set this to modified since the new rpm is built into errata-candidate. greetings, Florian La Roche
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?
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. http://rhn.redhat.com/errata/RHBA-2003-254.html
----- Additional Comments From jstultz.com(prefers email via johnstul.com) 2004-02-17 19:59 ------- This bug has been addressed by the RH errata: http://rhn.redhat.com/errata/RHBA-2003-254.html The RH bug #91927 has been closed for some time. So I'm closing this as well.