Results 1 to 2 of 2
Running with the RHEL 5.4 64bit operating system. Have a number of systems randomly reporting the bogomips higher "5560" vice "5067" being normally seen on the other 5.4 servers. When ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 09-19-2011 #1
- Join Date
- Sep 2011
Issues with "bogomips" and timing
Running with the RHEL 5.4 64bit operating system. Have a number of systems randomly reporting the bogomips higher "5560" vice "5067" being normally seen on the other 5.4 servers. When I reboot the server the bogomips go back to what I consider to be correct "5067".
When I get this random higher bogomip setting, it's impacting my timing on the server. I can stop and restart the ntpd, but with the initial detection of a higher processor speed and bogomip setting, restarting the ntp daemon will not correct my timing issue. I'm not seeing any issues with time on the multiple servers that detected the cpu processor speed and bogomips correctly?
Any issues with RedHat related to the caculation of processor speed and bogomips?
Here is what I've tried:
-The hardware clock is correct, but the system time lags behind. The longer the unit runs, the further behind the system time gets.
-`ntpq –p` shows that it knows which NTP server it’s trying to get to, but it’s not locked, and the offset and jitter are huge.
-`ntpdc –c sysinfo` shows that it’s got no system peer and no reference ID.
-Restarting ntpd sets the system time right, but it immediately starts to fall behind, losing a second within a few seconds, when comparing to the hardware clock.
-Setting the system clock from the hardware clock using `hwclock –hctosys` also sets the system time right, but then it also starts falling behind immediately.
-The only thing we’ve found that fixes the NTP problems is to reboot the unit.
-In /var/log/dmesg, the processor is detected as ~2.8GHz and the BogoMIPS is calculated as ~5560. On units that work properly, the processor is detected as ~2.533GHz and the BogoMIPS is calculated as ~5067. We tried turning the Intel TurboBoost option off in the BIOS, but that didn’t seem to help.
- 09-20-2011 #2
- Join Date
- Jan 2011
- Fairfax, Virginia, USA
I've had a problem almost like what you are describing on an embedded card running Linux with an incorrect crystal (XO) about a year ago. From what I remember, I was able to determine an approximate bias and correct it using adjtimex which allowed ntpd to synchronize. What adjtimex(1) does is invoke the system call adjtimex(2) and its easy to just write a "C" program to do what you want in case you cant download the command line tool (see the URL below). I seem to remember I deleted the file referred to in ntp.conf as "driftfile" (its usually /var/lib/ntp/drift), adjusted things with adjtimex then waited for ntpd to create the file again (it takes about 30 minutes if things are working).