If there is no asterisk (*) in the first column in the "ntpq -p" output, the ntpd service has _not_ synchronized with a NTP server, so it cannot correct the system clock effectively.
Your offset value (estimated difference of the time value between your ntpd and the NTP server) is -268.90 ms: this is currently too much. For successful synchronization, the offset would have to be smaller than 128 ms (positive or negative).
The root cause for non-synchronization is probably the high jitter: if the round-trip delay in the communication between ntpd and the NTP server has more than about 100 ms of jitter, ntpd will drop out of sync so often that it will be almost useless. (The NTP documentation says the jitter value is an exponentially weighted root-mean-square average deviation from the average delay.)
In practice, the large jitter value means that the travel time of the NTP time message from the NTP server to your ntpd is not predictable enough. Jitter usually becomes high when you're trying to synchronize time over a very congested/overloaded network connection.
If you have other servers connected to the same switch as this BL460c blade, the congested connection might be the one between the blade and the switch. If possible, you should take a look at the switch port statistics and find out how busy the blade's network interfaces are.
If you have only one active network interface, consider setting up bonding to get more network bandwidth to your blade.
MK
MK
