Home/Support/Support Forum/Synchronizing CP RTC time

Synchronizing CP RTC time

0 votes
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?

<datetime>Mon Jun 23 15:30:03 2014</datetime>
<datetime>Mon Jun 23 15:33:37 2014</datetime>
<datetime>Mon Jun 23 15:33:25 2014</datetime>
<datetime>Mon Jun 23 15:33:08 2014</datetime>
<datetime>Mon Jun 23 15:33:31 2014</datetime>
asked Jun 23, 2014 in NDS-based Gateways by mcarangi New to the Community (1 point)
recategorized Jan 14 by michaelt

Please log in or register to answer this question.

1 Answer

0 votes
This appears to have been a firmware bug resolved at the level (which correlates with your <datetime> outputs).

See the CP-X4 Firmware Release Notes file for additional details:



82001536_K ( - 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.
answered Jan 14 by michaelt Veteran of the Digi Community (741 points)
Contact a Digi expert and get started today! Contact Us