06-24-2013 06:06 AM
We have three Hp b2600 named rop11, rop12, rop13.
rop11 is active and rop12 is passive and rop13 is stand alone.
rop's are time syncronised with GPS clock. But we are facing a problem in time synchronisation.
As we sychnisied the time after a day we saw a drift of 10 sec roughly in rop11 and 1-2 second in rop12& rop13.
ntpq is showing as per attched file.
Tw file attched one is Parallet1 where the problem exist and Another is PArrallel2 where its working OK.
Pl. suggest the cause and remedy.
Solved! Go to Solution.
06-24-2013 12:10 PM
OK, so I seen your other post before this one. So, obviously you know that this is a UX workstation - it was not easy to determine what you were asking for in that other post.
Given the age of the systems, I would suspect the battery driving the clocks. I did some quick research and I did not find any mention of a "real time clock" module for the B2600 models. That leads me to beleive that the clock uses the system board coin battery. I would simply replace that. Those batteries are standard and you should be able to find a replacement easy enough.
06-24-2013 11:14 PM
We have found one Real Time chip on b2600 workstation mother board detailed as
and replace the same.
Is this real time chip has any significance in time synchronisation/drift.
06-24-2013 11:26 PM
In "Parallel1.doc", the ntpq "peers", "opeers", and "lopeers" commands have all zeroes in the "reach" field. That means ntpd has not been able to access any of the other servers (nor the local reference clock) successfully.
The local reference clock seems to be something called "H&B ContronicP Reader". Yet its "remote" field in the "peers" listing says "IRIG_TPRO", which suggests this NTP reference clock driver:
But according to that webpage, the IRIG_TPRO driver is for a device designed for the Sun workstation???
Googling for "H&B ContronicP Reader" indicates Contronic P is a series of automation and control system modules, manufactured by Hartman & Braun.
Perhaps this is a custom driver, for Hartman & Braun Contronic P series modules, reusing the IRIG_TPRO identifier? In that case, maybe the driver is just for getting the time off the automation module bus, and the actual clock is managed elsewhere? Such a custom driver might have very limited error detection and reporting. You would need to find the documentation for that custom driver and follow any troubleshooting information included in it. If you have other ways to diagnose the GPS clock hardware, you might try that too: if there really is an automation module bus, perhaps have an automation bus engineer (or someone who understands the automation bus) verify that the time information is actually present on the bus somehow?
Comparing the "Parallel1.doc" and "Parallel2.doc", the "clocklist" command will report a value in the "timecode=" field when the system is working OK, but when it is not, the timecode field is empty. So, in the situation of Parallel1.doc, the NTP reference clock driver does not seem to be getting any valid time information from the actual "GPS clock", wherever that is. As the "reach" field is all zeroes, it seems that the xntpd daemon has failed to communicate with the other rop* systems too. So in that situation, ntpd is unable to synchronize the clock, since it has no valid source of time information to synchronize with.
The inability to communicate with the other rop* systems might be incorrect configuration (bad IP addresses) in /etc/ntp.conf, or it might be network communication issues (firewalls blocking UDP/123, or maybe no network connectivity at all?).
The inability to communicate with the GPS clock might be caused by the same reason, or by something else, depending on what the actual GPS clock hardware is and exactly how it is connected to the HÅ B2600 system. There is not enough information to determine why the GPS clock connection fails, but it obviously is failing in Parallel1.doc.
06-25-2013 10:20 PM
We have Hopf GPs clock and which gives times to CMC 70 controller card of ABB symphony system which through network give time to rop's.
Now as per Parallel1.doc all values are zero and server it also not reachable . How to check NTP is running and XNTPD is running? Settings in the ntp.conf files are Ok showing two servers, peers & drift file.
06-26-2013 06:44 AM
If xntpd is not running, then ntpq would not display those lists at all. Instead, it would display a single error message:
"ntpq: read: Can't assign requested address". (Yes, it is not a very clear error message.)
So your output in Parallel1.doc already confirms that xntpd is running on the ROP, but it is indicating that it cannot communicate with neither the GPS clock (using whatever protocol the clock driver uses) nor the other ROPs (using NTP).
In the output of the ntpq *peers commands, the "poll" column indicates how often xntpd is attempting to query each time source - in this case, with intervals of 64 seconds. The "when" column indicates the number of seconds since the last attempt: when the "when" number becomes equal to the "poll" number, a new attempt is made and the "when" counter for that time source is reset. Since the different pictures in Parallel1.doc show different (increasing) values in the "when" column, xntpd is sending NTP queries to other rop* servers - but the zeroes in the "reach" column it is not getting any answers at all.
If your GPS clock is also accessed through the network, the root cause of your time synchronization problem might actually be a network connectivity issue.
Unfortunately I'm not familiar with the ABB Symphony system, so I cannot give suggestions about troubleshooting it.