time problem

[Mcgrawhill]

hi dear friends
I have 9 dl380 hp servers which are connected to two ntp servers(bl25) I have a problem with two server's time. Sometimes, they loose their synchronization with ntp server and the time goes back 5 minutes, suddenly.
My server's OS is redhat linux enterprise 4 (RHEL4) and I use NTPD daemon on each of them.

[Matti_Kurkela]

What's the kernel version you're using, and what generation are your DL380s? The full model number is something like DL380 Gx, where x is the generation number.

The newest CPUs have various systems to minimize unnecessary power consumption: if the kernel does not have support for those systems, it may interfere with the system clock.

Do you see any unusual messages in the kernel message buffer? Run "dmesg" to see the latest kernel messages. If you don't have iptables firewall logging configured, you can often see all the messages starting from when the server was started.

RHEL4's current kernel version should be something like "2.6.9-55.0.2" if you're fully up to date. If you're running RHEL4's original kernel, you're *guaranteed* to have trouble with dual-core CPUs: I think dual-core CPUs were not officially supported until RHEL4 Update 1 or 2.

Is the system's hardware clock in approximate sync with the OS clock? Run "hwclock" and "date" and compare the results. When ntpd is running and synchronized with a NTP server, it should periodically update the HW clock. If there is a large difference between the two, it might be a kernel problem or maybe somebody or something might be setting the OS clock manually.

Are the two NTP servers both sending correct time information? Are they syncing with each other (as NTP peers) or otherwise *exactly* in agreement?

Do you see any NTP synchronization messages in the system logs? How does NTP behave just before losing sync? Is it flip-flopping between the two NTP servers?

Two NTP servers is just about the worst possible amount: if the NTP client is not configured to have its own internal clock as a fall-back timesource and one of the NTP servers starts sending incorrect time, the client has no way to detect which one of the servers is wrong and which is right.
With three timesources (e.g. two servers and the client's internal clock, if it's accurate enough) the NTP client can identify a faulty timesource and automatically stop trusting it.

MK