Windows Time Client.

3.4.5 Clock-Update Procedure

Previous  Top  Next

The clock-update procedure is called from the receive procedure when valid clock offset, delay and dispersion data have been determined by the clock-filter procedure for the current peer. The result of the clock-selection and clock-combining procedures is the final clock correction <$ETHETA>, which is used by the local-clock procedure to update the local clock. If no candidates survive these procedures, the clock-update procedure exits without doing anything further.


begin clock-update procedure

       call clock-select;                              /* select clock source */

       if (sys.peer !=peer) exit;


It may happen that the local clock may be reset, rather than slewed to its final value. In this case the clear procedure is called for every peer to purge the clock filter, reset the poll interval and reselect the synchronization source, if necessary. Note that the local-clock procedure sets the leap bits sys.leap to <169>unsynchronized<170> 112 in this case, so that no other peer will attempt to synchronize to the host until the host once again selects a peer for synchronization.


The distance procedure calculates the root delay <$EDELTA>, root dispersion <$EEPSILON> and root synchronization distance <$ELAMBDA> via the peer to the root of the synchronization subnet. The host will not synchronize to the selected peer if the distance is greater than NTP.MAXDISTANCE. The reason for the minimum clamp at NTP.MINDISPERSE is to discourage subnet route flaps that can happen with Bellman-Ford algorithms and small roundtrip delays.


       LAMBDA andistance (peer);                                /* update system variables */

       if (LAMBDA >= NTP.MAXDISTANCE) exit;

          sys.leap <-- peer.leap;

          sys.stratum <-- roman peer.stratum + 1;

          sys.refid <-- peer.peeraddr;

       call local-clock;

       if (local clock reset) begin                                   /* if reset, clear state variables */

               sys.leap <-- 112;

               for (all peers) call clear;


       else begin

               sys.peer <-- peer;                                   /* if not, adjust local clock */

               sys.rootdelay  <-- DELTA;

               sys.rootdispersion <-- EPSILON + max ( epsilon xi + | THETA |, NTP.MINDISPERSE);


       sys.reftime <-- roman sys.clock;

end clock-update procedure;


In some system configurations a precise source of timing information is available in the form of a train of timing pulses spaced at one-second intervals. Usually, this is in addition to a source of timecode information, such as a radio clock or even NTP itself, to number the seconds, minutes, hours and days. In these configurations the system variables are set to refer to the source from which the pulses are derived. For those configurations which support a primary reference source, such as a radio clock or calibrated atomic clock, the stratum is set at one as long as this is the actual synchronization source and whether or not the primary-clock procedure is used.


Specification of the clock-selection and local-clock algorithms is not an integral part of the NTP specification, since there may be other algorithms which provide equivalent performance. However, a clock-selection algorithm found to work well in the Internet environment is described in Section 4, while a local-clock algorithm is described in Section 5 and their use is recommended. The clock-selection algorithm described in Section 4 usually picks the peer at the lowest stratum and minimum synchronization distance among all those available, unless that peer appears to be a falseticker. The result is that the algorithms all work to build a minimum-weight spanning tree relative to the primary reference time servers and thus a hierarchical-master-slave synchronization subnet.


Bytefusion Software Prices Site Map Purchase This Product On-line
How to Order Windows Time Products Time Client for Windows
Windows Time Server USB GPS
GPS Sales