On Sun, 2006-12-17 at 01:09 -0600, Darryl Gregorash wrote:
On 2006-12-17 00:00, ByteEnable wrote:
<snip> Yeah, I deleted the /etc/adjtime file, played with hwclock, played with ntp, etc. Its just no workie. <sigh>.
Byte
Stop ntpd, delete that file *and* /var/lib/ntp/drift/ntp.drift, then:
grep USER_HZ /usr/src/linux/include/asm/param.h
param.h:# define USER_HZ 100 /* .. some user interfaces are in "ticks" */
adjtimex -p mode: 0 offset: 0 frequency: 0 maxerror: 16384000 esterror: 16384000 status: 65 time_constant: 6 precision: 1 tolerance: 33554432 tick: 10000 raw time: 1166350769s 215998us = 1166350769.215998 return value = 5
In the latter, the value of "tick" should be 1 million/USER_HZ. If not, then run: adjtimex -t <val> -f 0 -o 0
with <val> equal to that value. Now running "adjtimex -p" again should show that "tick" has that value, while the values of "offset" and "frequency" are zero.
The system clock will now be running in an uncorrected, "raw", state. Use "hwclock --hctosys" to bring the system clock into agreement with the hardware clock.
Now run "adjtimex -c" to determine any discrepancy between the rates of the system and hardware clocks. Comparisons are 10 seconds apart, and after the first two, adjtimex will suggest values of "tick" and "frequency" that will keep the two clocks at the same rate.
--- current --- -- suggested -- cmos time system-cmos error_ppm tick freq tick freq 1166348614 1.782604 1166348622 3.565470 178286.6 10000 0 1166348630 5.348385 178291.5 10000 0 8217 556300 1166348638 7.131298 178291.3 10000 0 8217 570362 1166348646 8.914216 178291.8 10000 0 8217 537550 1166348654 10.697123 178290.7 10000 0 8217 609425 1166348662 12.480035 178291.2 10000 0 8217 576612 1166348670 14.262944 178290.9 10000 0 8217 596925
Also use "adjtimex -h <timeserver>" at least twice, over a period of at
The estimated error in the cmos clock is 0.710913 +- 0.000014 ppm
least a couple of hours (the longer the better). Do not reboot the system, do not run the ntp daemon, and do not set any time variables in either system or hardware clocks, during this time to ensure accurate calculations. If /var/log/clocks.log exists, delete it before the first run. Starting with the second run, adjtimex will calculate errors in the frequency, in ppm, for each of the system and hardware clocks.
It's probably a good idea to let us have a look at the results of all this at this point.
-- The best way to accelerate a computer running Windows is at 9.81 m/s²
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org