A-Class server time synchronisation problem

[Yeow Peng]

Hi all,

I faced some problems with A-class servers synchronisation problem. After every restart of xntpd daemon, time is slew back with its preferred time server. But after 1 or more days, one or more servers being to lose its preferred time server sychronisation (using ntpq -p).

Is there any ways that I could resolve this issue? Is restarting xntpd daemon through cronjob every week helpful?

Thanks all for your help.

regrds,
yeow peng

[A. Clay Stephenson]

First, you really don't want to have a preferred NTP server; instead, you want the NTP clients to choose their server based upon current statistics. I would remove the preferred designation from ntp.conf and at the same time make sure that at least 3 timeservers are available to choose from. (Public internet time sources will do just fine for all but the most demanding networks.) After this is done, run ntpq -p from each of the clients and make certain that the "reach" column is pegged at 377 after a few tens of minutes of operation. If the network is not stable enough to keep reach at 377 then NTP will never be reliable.

You do't mention the the exact A-model but there was a firmeware patch to correct exytreme drift in the realtime clock for some A's. I would also check that as well.

[Yeow Peng]

Hi,

These A400 servers are configured such that it synchro with 2 timeservers in a private LAN. But after one or more days, one or more servers begin to lose its time sychronisation from its current preferred timeserver (*) retrieved from ntpq -p output.

Does the HP patch able to solve this problem? Please advice.

Thanks all for your help.

Regrds,
yeow peng

[Yeow Peng]

Hi,

The A400 servers are configured to synchro with internal main clock (2 timeservers) in a private LAN. But after one or more days, one or more servers slowly begin to lose its time synchronisation from its current preferred timeserver(*) retrieved from ntpq -p output.

Does a HP patch solve this problem? Please advice.

Thanks all for your help.

Regrds,
yeow peng

[A. Clay Stephenson]

Is your reachability pegged at 377? If not, go no further because this is hopeless. Having 2 time servers is not very wise because the clients have a very difficult time deciding which one is best. If two NTP servers are drifting and the client's realtime clock drifts as well (they all do), how can the client decide which one is the better (more accurate) time? That's why you need at least 3. The client can then choose based upon a majority of servers.

The firmware patch would only correct the realtime clock problem but once NTP synchronization is achived has no bearing on your problem. You might look for NTP patches but unless you correct your fundamental NTP setup, nothing is going to help.

[Steven E. Protter]

Shalom,

As a general practice, having a recent bi-annual patch set can help with many problems including this. Regardless its a good idea to have such patches installed for system stability.

To be certain a particular patch is going to help, read the patch notes.

Searching the patch database for ntp patches and reading the patch notes is likely to find you some candidates to help.

Also ntpd can only properly sync time if the time of the server and client are within a few hours of each other.

It would be a good idea to set the system time to within an hour of the time server time and then start ntp and see what happens.

I think this seems like a situation where you want to look for a patch.

SEP