The following is the RTC setting returned from 5 Connect Port X4 GWs using the iDig web services. All GW RTC and FQDN are setup similarly. The only significant difference in the GWs that I can determine is the version of FW.
The 1st RTC time shown below was returned for a GW with FW ver 2.13. the others are ver 2.14 to 2.17. I can accept a few seconds difference in time but how can the > 3 minute difference be explained?
Mon Jun 23 15:30:03 2014
Mon Jun 23 15:33:37 2014
Mon Jun 23 15:33:25 2014
Mon Jun 23 15:33:08 2014
Mon Jun 23 15:33:31 2014
This appears to have been a firmware bug resolved at the 184.108.40.206 level (which correlates with your outputs).
See the CP-X4 Firmware Release Notes file for additional details:
82001536_K (220.127.116.11) - October 14, 2011
The clock (time) source management functionality has been improved to better detect failures to retrieve time sync samples from an NTP server as a time source. Failures or “lost” replies result in quick retries for both the initial sample after boot time as well as for subsequent samples. Additional configurability is supported via the “set timemgmt” CLI command, the web UI and the iDigi platform. Event logging is improved for time-related events.
For the clock (time) source management feature, update the web UI and web help to include the configurable jump threshold and “lost time source” detection settings.
For the clock (time) source management feature, improve the SNTP client implementation:
- Add detection of “expired” NTP replies.
o Accept replies only if in response to the most recently issued request for a given NTP time source. Discard other replies.
o Replies must not be more than 20 seconds since the request was sent. Old samples can skew the time computation and cause undesired jumps.
o Add a statistical counter for “expired” replies (“info time” CLI).
- Improve the NTP reply read resolution for the socket, to more quickly process replies.