The Network Time Protocol (NTP) can be used as an external clock source to synchronize the ACE3600 RTU over IP with one or more NTP servers.
In the MOSCAD system, the NTP works in client/server mode, in which a client RTU polls another server and gets a reply. The server can be another RTU operating NTP, or a host (PC, Unix, Linux). NTP poll the server RTU every 2 seconds, every 4 seconds, 8 and so on, up to a poll every 17 minutes. NTP provides client accuracies typically within a
millisecond on LANs and up to 100 milliseconds on WANs (Internet, GPRS). Any RTU (usually FEP) can act as a server. This enable setting its time via MDLC time sync, for example, and having other RTUs specify it as an NTP server and obtain their time from it.
NTP synchronizes clock both in time and frequency. In time means it make its clock offset as close as possible to the server. In frequency means it learns the server drift (time between “ticks”) in order to avoid polling it every few seconds. An example, not related to NTP, is ACE3600 send MDLC Sync over radio to another ACE3600. The clock offset guaranteed to be less than 1 millisecond. However a 30ppm clock drift after 1 minute offset will be 1.8 milliseconds. NTP prevents that by learning the drift frequency of the server.
User can set a single NTP server, or several ones. NTP operates under the assumption that each server's time should be viewed with a certain amount of distrust. NTP really prefers to have access to several sources of lower stratum time (at least three) since it can then apply an agreement algorithm to detect insanity on the part of any one of these. Normally, when all servers are in agreement, NTP will choose the best of these, where "best" is defined in terms of lowest stratum, closest (in terms of network delay) and claimed precision, along with several other considerations.
As the below figure shows, at the top of any NTP hierarchy are one or more stratum 0 reference clocks. These are electronic clocks such as GPS signals, radio signals, or extremely accurate frequency control. Reference clocks are assumed to be accurate. In ACE3600 a GPS port can be configured, it will serve as a reference clock for that RTU. In this case RTU will operate on stratum 1 with an accuracy of 200 microseconds.
Clock Functions and Synchronization
Figure 1 NTP architecture
As the above figure shows, time is distributed from an NTP subnet of servers. Each server comprises a stratum, which designate its location in terms of hops to the UTC source. The stratum 1 is the most accurate server of which all servers should be synchronized to. Up to 15 stratum levels may exist. Stratum 16 means server unreachable.
The accuracy of other clocks is judged according to how “close” a clock is to a reference clock (the stratum of the clock, the network latency to the clock, and the claimed accuracy of the clock. The accuracy of NTP thus depends on the network environment. Because NTP uses UDP packets, traffic congestion could temporarily prevent synchronization, but the client can still self-adjust, based on its historic drift. Under good conditions on a LAN without too many routers or other sources of network delay, synchronization to within a few milliseconds is normal. Anything that adds latency, such as hubs, switches, routers, or network traffic, will reduce this accuracy. The synchronization accuracy on a WAN is typically within the range of 10-100 ms. For the Internet/GPRS synchronization accuracy is unpredictable, so special attention is needed when configuring a client to use public NTP servers. Testing with the ACE3600 connected with the Internet gains accuracy of 20-30ms, but theoretically it may be even 100ms.
NTP uses UTC time base (Coordinated Universal Time). UTC evolved from Greenwich Mean Time (GMT). GMT is based on the earth’s rotation, which is not constant enough to be used for detailed time measurements. UTC is based on a standard second length
determined by the quantum phenomena. There is a difference of a few seconds between the two (14seconds in 2006), so every several years add one more second (called leap second) to UTC. This is built in NTP protocol.
To translate the UTC time into local time, user can configure Time zones and Daylight Savings in RTU. Note however, that if setting NTP server to another stand alone ACE3600, which has no time zone, both will operate with the same local time if no time zone set. If that ACE3600 is connected to a GPS or to another NTP server then there is a need to set a time zone.
Clock Functions and Synchronization
NTP Setup
1. In MDLC over IP port (either RS232 PPP or 10/100 BaseT) select up to three NTP servers. In some systems, where NTP servers are not available, specify another RTU/FEP ACE3600. The IP address of NTP server can be either numeric such as 10.17.1.161 or host name such as www.ntp.comm.mot.com . The later format can be used only if DNS servers were set or learned from the network. If you have several MDLC over IP port, you can set-up several NTP servers, but make sure the above tree structure is preserved.
2. Connect this server to a GPS or to another NTP server(s). Another option is not to configure it with any GPS and NTP servers.
3. Set time zone. In the above first two cases you also need to set time zone in advanced parameters, so it operates in local time. In the last case, where using a stand alone ACE3600 as a server (no GPS and no NTP configured) there is no need to set a time zone.
4. Make sure all servers are in sync. If you configure your primary sever as connected to GPS, make sure it is able to receive satellites. Check GPS level 1 and NTP level 1 to see it is synchronized, otherwise it will not be regarded as a valid server. If your primary server is not configured for GPS and to any other NTP server, it is OK, but make sure you have only one like that or sync it periodically to avoid clock drift from other servers (for example by time sync it every few minutes).
The NTP advanced parameters explained in ACE3600 STS User Guide, Appendix A Site configuration parameters. The most important parameters are shown below:
Max sync offset in msec <0-500> [0]:
The maximum permitted offset of the RTU clock from its NTP server(s). If the offset exceeds this amount, the NTP servers will be polled frequently to correct the offset,
possibly causing a heavy communication load. When set to 0, the offset is not checked. It is recommended to leave this parameter set to 0.
Minimal poll interval in sec <1-64> [4]:
The minimal interval in seconds between polling the NTP server(s). NTP works by polling its servers. This is the minimal time in seconds that is polled. After a poll and sync, the interval to the next poll is multiplied until reaching the ‘Maximal poll interval in seconds’.
(See the next parameter.)
Note: When contact with the server is lost, the minimal poll interval is used to resync as fast as possible.
Maximal poll interval in seconds <1-1311072> [1000]:
The maximal interval in seconds between polling the NTP server(s). See ‘Minimal poll interval in sec’ above. 1000 seconds is ~17 minutes.
Transmit BURST when poll <Yes/No> [Yes]:
Clock Functions and Synchronization
If this parameter is set to YES (default) when polling 8 messages are sent instead of one every 2 seconds apart in order to sync as fast as possible. If NO only a single poll message is sent.
Time sync lost before declare ‘no sync’ in sec [120]:
The number of seconds to wait before declaring ‘no sync’ state after being in sync. When no reply is received from the NTP server(s), or when getting invalid replies ‘no sync’ is declared, and the ClockValid in the Reserved Flags database system table is set to 0. 120 by default means it takes 2 minutes to indicate that.
Notify error logger when losing sync <Yes/No> [Yes]:
Whether notification should be sent to the error logger when declaring ‘no sync’. By default this parameter is "YES", meaning a message is logged into error logger when getting into "no sync" state after being in sync. If ‘no sync’ again, no message is logged until the user retrieves SW diagnostics device NTP level 10.
NTP Diagnostics and Verification
To verify that NTP is functioning properly, use the STS SW Diagnostics, the Error Logger and the ladder application database:
1. Check STS SW Diagnostic device NTP level 1. If it is operative, it will shows “clock synchronized” and the current clock offset.
2. An error is logged if synchronization is lost from all NTP servers.
3. Check the application database system table Reserved flags field ClockValid. If it is 0, this means NTP is not functioning properly.
Note: When NTP is OK (synced) the ClockValid flag is set to 1 in database system Reserved flags table. In this case, the ACE3600 will inhibit any user attempt to change the clock, either from the database monitor, STS Site Date & Time, or when getting an MDLC Time Sync message. It could however, send an MDLC Time Sync to other RTUs as initiated from a local connected STS, or from user application.
To check the NTP servers status:
1. Check STS SW Diagnostic device NTP level 2. It shows the list of NTP servers.
Sun Oct 29 10:33:07 2006 SITE: 2 LINK: LINE 2 DEVICE: NTP LEVEL: 2
Fail Prev Next
Peer address port assoc Strat test Flags poll poll delay offset disper. maxrxtime
--- ---- --- --- ---- ---- ---- --- --- --- --- ---
10.5.1.160 ETH1 30780 16 0000H 0301H 617 409 0.000 0.000 0.000 0.000
*10.5.1.161 ETH1 30781 10 0000H 0341H 505 518 1.125 -0.729 0.071 3.396
Clock Functions and Synchronization
The first column shows the status of the NTP server. 10.5.1.160 is unreachable because it has no symbol, and 10.5.1.161 is reachable ‘*’ marks it as a system peer. Both are polled via ETH1. The stratum of the system peer is 10 meaning this is an ACE3600 which is not connected to any NTP server or GPS receiver, otherwise it would have much smaller stratum. The Prev and Next Poll designate in seconds when last time polled and when will next poll occur. The delay is in milliseconds says 1.125 milliseconds delay to server. The offset is also in milliseconds –0.729 milliseconds. The dispersion says how stable is the clock, the less it is the better the clock. maxrxtime is for internal use.
Another method of testing NTP is using ntpq <ACE3600 IP address>. This utility is provided in the STS installation and is a standard way of testing NTP. Refer to
http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html for information on how to use this utility. The most common commands are rv and pe to show clock status and NTP servers.