Recognize time synchronization needs in control networks

What you should be able to do

Distinguish clock offset from packet delay, identify application-specific synchronization requirements and recognize the evidence needed when time quality degrades.

Read the timing diagram

The upper example compares two clock readings at the same actual instant. The reference reads 12:00:00.000 and the device reads 12:00:00.004. The device is four milliseconds ahead. The lower example follows a packet from sending to receiving. Its elapsed delay is two milliseconds on a common reference timescale. It is a separate fictional example, not a calculation from the two clocks above. Subtracting timestamps from unsynchronized devices can mix actual travel time with clock offset. A link indicator does not tell you either quantity accurately.

What synchronization provides

An application may need event timestamps that can be compared across devices, coordinated actions or time-aligned measurements. Those needs do not necessarily have the same accuracy requirement. The owner must state the required time reference, endpoint error limit, operating conditions and evidence method. Avoid selecting a universal tolerance merely because the network carries control traffic or uses fiber.

Protocol and system evidence

PTP, the Precision Time Protocol, uses clock roles and configuration choices that must match the intended system. Cisco’s industrial-switch guidance distinguishes profiles and modes such as boundary and transparent clock behavior [1]. Exact support depends on hardware and software. NIST’s NTP research identifies network delay asymmetry as an important source of time-transfer error [2]. The general lesson is to evaluate the actual timing path and measurement uncertainty rather than assume the protocol name establishes accuracy. No PTP or NTP accuracy guarantee is supplied here.

Clock roles in context

Identify the authoritative time source and how time reaches the endpoint. For a PTP design, verify required profile, domain, delay mechanism and supported clock roles against the exact configuration. A boundary clock synchronizes upstream and supplies timing downstream. A transparent clock accounts for relevant forwarding delay in timing information. These functions are not interchangeable labels to apply to every switch. The project must establish how the selected devices implement the required behavior. A supported optical port alone does not establish supported timing functions.

Original event-ordering exercise

Clock A is four milliseconds fast relative to the common reference. Clock B is three milliseconds slow. Two events occur simultaneously in actual time. A’s reported timestamp is seven milliseconds later than B’s: +4 − (−3) = 7 ms. A log viewer could therefore suggest an order that did not exist. This example shows why clock-quality evidence matters when comparing event records. It does not specify the accuracy required for any real process.

Original delay exercise

A packet is sent when the reference time is 0 ms and arrives when reference time is 2 ms. The receiving device’s clock is four milliseconds fast. Its receive timestamp is therefore 6 ms. Subtracting the sender’s 0 ms timestamp from that uncorrected reading would report 6 ms, although the actual packet delay is 2 ms. This is simple classroom arithmetic, not a complete NTP/PTP estimation algorithm.

Loss of synchronization

Document how a device indicates source loss and what its application does with degraded time. Some systems continue using a local oscillator in holdover; their error can grow while disconnected from the reference. Do not assume that data forwarding stops when timing fails, or that normal Ethernet traffic proves synchronization remains acceptable. The status, alarms and required response must be specified separately.

Original holdover exercise

Assume a fictional clock begins holdover with an error magnitude bounded by 1 ms. Its supplied simplified model adds up to 0.2 ms of error per minute in the unfavorable direction. After ten minutes, the bound is 1 + 0.2 × 10 = 3 ms. If the fictional application allows at most 2 ms, that model reaches the limit after five minutes and exceeds it afterward. Real holdover behavior depends on the actual clock and conditions; this invented linear model is not a product specification. Document the required source-loss alarm and application response rather than relying on an assumed drift value.

Acceptance evidence

Measure or otherwise verify the specified endpoint timing error using an appropriate reference and method. Record the clock state, profile/configuration, source identity, topology, load and uncertainty. Include agreed source-loss and restoration cases. A normal status flag is useful evidence, but it does not replace the endpoint accuracy check required by the project. Perform any tests under the approved control-system plan. Do not change time sources or clock settings on live systems for this classroom exercise.

Worked through

Record application purpose; reference timescale; maximum permitted endpoint error; normal and degraded conditions; time source; protocol/profile and device roles; network/path assumptions; measurement method and uncertainty; source-loss indication; holdover evidence; restoration behavior; owner and acceptance record.

Practice questions

1. What is clock offset?
2. Is packet delay the same quantity?
3. How far apart do simultaneous events appear with A at +4 ms and B at −3 ms?
4. In the delay exercise, what is the actual packet delay and misleading timestamp difference?
5. What is the fictional ten-minute holdover bound?
6. Does a healthy fiber link prove synchronized clocks?
7. Who sets the permitted timing error?

Answers

Where beginners go wrong

Sources