Add an attachment proposed patch, testcase, etc. None edit Description Craig Goodyear The value stays at the starting value of 0. Comment 1 Miroslav Lichvar It can take some time before the value is updated. If it was longer than few hours then probably ntp didn't reached a stable state. Can you please post output from command "ntpq -p" and relevant lines from syslog?
Comment 2 Craig Goodyear Comment 3 Miroslav Lichvar Can you please also send another ntpq -p output when the ntpd runs for at least an hour? Comment 4 Craig Goodyear Here is a current listing with ntpd running for about 24 hours.
One is a network connectivity problem, 37 in the reach column means that from last 8 attempts to connect a ntp server only 4 were successful. Second is the system time, every minutes there is a time reset about -3 seconds. The time is running much faster than ntp can handle.
Reassigning to kernel component. Comment 7 Craig Goodyear Comment 8 David A. De Graaf Since installing FC5 the ntpd servo operation has failed to adjust the clock rate, but merely did a time reset when the time error grew too large.
For example, logwatch for the past three days reported: Time Reset 54 times total: Before that it had a fixed value of In a futile attempt to restore normal servo operation, I removed the drift file.
I noted that a new one was created with the 0. Yesterday I discovered this bugzilla report with Craig Goodyear's workaround. I immediately tried turning off the "spread spectrum" feature in the BIOS - both of them - and there have been no time resets at all in the past 48 hours. Normal ntpd servo operation is working again. The drift file has stepped thru values: The ntpd servo has worked perfectly in the past on this machine.
This clearly proves that FC5 introduced this new bug. Comment 9 Dave Jones Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem.
Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: See bug for further details.
If this bug is a problem preventing you from installing the release this version is filed against, please see bug If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Comment 10 Craig Goodyear Comment 11 David A.
There is another available setting of 1. However, the clock is now being reset occasionally, whereas it wasn't before: Comment 12 Dave Jones The ntp code was being miscompiled by the fc5 gcc.
It'd be good to know whether or not this fixes your problem. The spread spectrum stuff is probably completely unrelated btw. It's some voodoo that prevents RFI by modulating the system clock signal. Comment 13 Craig Goodyear After installing kernel 2. The problem had been corrected, ntpd worked normally with FSB spread spectrum enabled.
Comment 14 Dave Jones Comment 15 David A. I updated to kernel. Of course, these events have been minimal with kernel. There were 13 resets with the kernel, but none since Nov 6. Evidently, ntp stabilized somewhat. FWIW Thanks for fixing it.