Time Sync issue 800xA PM866 contoller with external Galleon Time Server
Hopefully you can help us with the following issue:
We having a time sync issue on our 800xA system. The PM866 controller won’t synchronize anymore with our external Galleon time server.
If we are looking at the controller log the time was synchronized in the past:
I 2016-12-09 21:20:33.689 SNTP: Synch by Time Server 10.230.80.101
I 2016-12-09 21:20:33.689 SNTP: External Time Reference is GPS
I 2016-12-09 21:20:33.690 SNTP: Stratum is 1
W 2016-12-12 07:54:15.078 SNTP: No reply , Server 10.230.80.101 dropped 1
I 2016-12-12 07:54:48.247 SNTP: Synch by Time Server 10.230.80.101
But now the log file shows the following alarm:
W 2017-04-13 14:19:15.957 SNTP: No accepted time server found, 2
I 2017-04-13 14:19:26.969 SNTP: Server 10.230.80.101 not synchronized (Alarm)
Why does it say: No accepted time server found?
Does this mean the time is not reliable or doesn’t sees the controller the time server at all?
If we PING form the timeserver to controller it replies.
See also the enclosed document
Voted best answer
Probably, the controller does not find the source reliable.
Try recording the NTP traffic (UDP port 123) - here below I have inserted two examples (tcpdump and Wireshark) of a controller (172.16.80.102) successfully reading time off the reference (172.16.4.254) which in turn is synchronized by ABB corporate network time:
# tcpdump -vvv -i xl0 udp port 123
tcpdump: listening on xl0, link-type EN10MB
13:39:58.768095 172.16.80.102.1030 > 172.16.4.254.ntp: [udp sum ok] v1 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt +1501846798.178713202 [tos 0xfc] (ttl 63, id 37119, len 76)
13:39:58.768175 172.16.4.254.ntp > 172.16.80.102.1030: [udp sum ok] v1 server strat 6 poll 0 prec -6 dist 0.015197 disp 0.000000 ref email@example.com orig 1501846798.178713202 rec -2085978495.410569071 xmt -2085978495.410559058 [tos 0x10] (ttl 64, id 22107, len 76)
Look at the stratum value (6 in my case).
I assume you noticed the problem???
The external clock is exposing a bad quality which causes the AC 800M controller to reject it. Also, have a look at the time stamps it provided - they are way off...
Compare with the capture I made.
The AC 800M NTP *client* is indeed using a strange "Transmit Timestamp" which the server returns in the "Origin" time field, however in my capture the server returns with valid data (Reference Timestamp) and a good stratum.
In your case, the server response is all bad data and a zero (bad) stratum.