Two sensors can agree on the wrong time. Precision synchronization becomes useful only when its reference, uncertainty and failure behavior reach the application.
The event that happened twice
Imagine a manufacturing research line investigating an intermittent vibration. One instrument records a change in motor current; another records movement in a fixture. The engineering team wants to know which changed first. Both files contain timestamps with many digits after the decimal point. The display looks precise. Yet the order remains uncertain because the instruments may not have been referring to the same moment, and because each may attach its timestamp at a different stage between sensing and saving.
This is a fictional example, not a reported factory incident. It illustrates why a clock is part of a measurement rather than an administrative accessory. A timestamp can become evidence for a causal story, a quality decision or a maintenance diagnosis. If its uncertainty is larger than the separation between the events, printing more digits does not rescue that story. If the uncertainty is unknown, apparent order can be worse than an openly incomplete record: it can encourage a confident explanation of something the system did not resolve.
There is a timely standards hook, although it is not evidence that every factory has adopted a new architecture. In May 2025, the IETF published RFC 9760, a standards-track enterprise profile for the Precision Time Protocol, or PTP, combining multicast and unicast messages. A profile constrains choices within the broader protocol for a particular environment. Its publication is a concrete interoperability development, not a guarantee of timing performance at an industrial sensor. RFC 9760.
The distinction is the heart of this article. A protocol can support a timing relationship; a profile can help devices use compatible options; a test can characterize a particular installation. None of those statements, separately, establishes that the final event record has the uncertainty needed for the decision being made. The useful question is not simply whether a device supports PTP. It is what the device's time means, where that meaning is measured, and what happens when the assumptions stop holding.
The research line will serve as an original worked example throughout. Its numbers are deliberately invented for explanation, not specifications, typical performance claims or recommendations for live control. Real industrial changes require qualified engineering and the installation's safety procedures. Here the purpose is to make the evidence readable enough that a buyer, investigator or public-interest reader can distinguish a timing capability from a timing assurance claim.
Three different promises hiding inside one number
Suppose two clocks show exactly the same value. That establishes agreement at the instant and resolution at which they were compared. It does not establish agreement with an external time reference. Both could be late by the same amount. Conversely, two clocks could each be close enough to an external reference for one purpose while differing enough from each other to frustrate a more demanding local comparison.
For the fictional line, the team separates three questions. First, how closely do the instruments agree with each other? Second, how closely does their common time correspond to the chosen external reference? Third, how closely does each recorded timestamp correspond to the physical event it is supposed to mark? These are related questions, but they are not interchangeable. A local experiment may care mainly about relative timing; a record compared across organizations may also require external traceability; a sensor study needs the event-association question in either case.
The third question often exposes the most useful disagreement. An engineer may be discussing the clock on a network interface, a software developer the operating system's clock, and an analyst the timestamp inside a saved row. They can all use the phrase synchronized clock while referring to different measurement points. A system diagram should put those points in separate boxes before any impressive accuracy figure is attached to them.
An original toy example makes the distinction visible. Let the network clock be correct within one arbitrary time unit. A sensor process waits an uncertain interval between five and nine units before asking that clock for the time. If the saved value is presented as the instant of sensing without accounting for that interval, the one-unit clock statement is not the complete event-timing statement. Improving the network clock by a factor of ten would leave the larger unresolved interval in place.
The example is not an argument against better clocks. It is an argument for locating the bottleneck. One installation may indeed be dominated by synchronization error; another by sensor response, buffering or software scheduling. The most valuable upgrade is the one that improves the uncertainty attached to the actual question. Procurement language that demands the smallest advertised number without identifying its measurement point can optimize an impressive subsystem while leaving the decision unchanged.
What a calibration study actually measured
NIST Technical Note 2030, published in December 2018, is useful because it follows timing through a real cyber-physical systems testbed rather than treating one clock specification as the whole system. The authors characterize reference calibration, network synchronization and device timestamping. Their report describes a power-related anomaly that changed the reference-calibration uncertainty, as well as measurements at different downstream points. These are historical results from a particular testbed, not a performance table for all current devices. NIST Technical Note 2030.
One detail matters especially when reading the report: its general-purpose input/output timestamping experiment used an NTP-synchronized embedded computer. It should not be represented as a final stage in the same PTP path used for every other measurement. Combining numbers from different experimental arrangements into a single degradation chart would produce a tidy but misleading picture. The paper's value lies partly in preserving those arrangements and their distinct questions.
For our fictional line, the corresponding editorial discipline is to demand a diagram before a ranking. If Vendor A reports an interface-clock comparison and Vendor B reports a complete event-to-file test, placing their error numbers side by side does not automatically compare equivalent products. The apparently worse result might include more of the system. The apparently better result might be entirely valid but answer a narrower question.
The team therefore writes an acceptance statement in ordinary language before it chooses the test instrument: for a specified class of events, at a specified sensing point, under specified operating conditions, the saved timestamp should have a documented relationship to the agreed reference. Each phrase carries work. A specified event prevents a convenient software marker from replacing the physical phenomenon. Specified conditions prevent a quiet demonstration from standing in for a busy shift. A documented relationship requires uncertainty, not merely a screenshot of two matching displays.
That statement is a proposed reasoning tool, not a quotation from the NIST report. It translates the broad distinction between measurement points into a question that a non-specialist can ask. It also gives different teams a shared object to discuss. The network team need not pretend to certify the sensor, and the sensor team need not pretend that its local response test certifies the network. Their evidence can meet at a clearly named boundary.
The conversation has a journey time
A timing message does not arrive at the same instant it is sent. Estimating the relationship between clocks therefore involves reasoning about travel time as well as reading timestamp fields. An exchange can reveal a round-trip interval, but splitting that interval into two one-way journeys requires assumptions or additional information. This is where the attractive simplicity of a clock display gives way to a measurement problem.
A 2016 NIST research paper by Michael Lombardi and colleagues discusses accurate, traceable and verifiable time distribution to financial markets. Its treatment of two-way exchange shows why unequal forward and reverse delays contribute uncertainty. The paper is also a documented time-distribution and verification study, not simply a product brochure. Its discussion of financial requirements belongs to 2016 and is not used here as current legal guidance. Lombardi and colleagues.
Consider an intentionally simplified exchange in the fictional line. Suppose the forward journey takes eight units and the return journey takes twelve. Their total is twenty. A model that allocates ten to each direction has the correct total and the wrong allocation. The difference between the actual forward delay and that assumed half is two units. A timing correction built on the equal-delay assumption can therefore be biased even though the measured round trip looks entirely plausible.
Now suppose the total remains twenty while the journeys become six and fourteen. A dashboard showing only the total would show no change. The allocation error would grow. This does not mean every round-trip measurement is useless. It means that an observable can constrain one property without uniquely determining another. The limitation is mathematical, not an accusation that the instruments are defective.
The team can use this example to improve its questions without turning the article into network configuration instructions. Which parts of the path are included in the measurement? Which are calibrated? Which changes might invalidate that calibration? What independent evidence would reveal an imbalance that the round-trip total alone cannot expose? Asking those questions is more informative than equating low network latency with known time accuracy.
A profile is an agreement about choices
Protocol support is often described as a yes-or-no feature. In a real procurement conversation, the more useful object is the combination of version, profile, supported options and tested interoperability. A broad standard necessarily accommodates different settings and applications. Two devices can advertise the same family name while expecting different arrangements around it.
The enterprise profile's contribution should be understood at that level: it narrows the options for its intended environment. It is not a replacement for every industry-specific profile, and it should not be promoted as the universal design for the fictional research line. The title itself identifies an enterprise setting. An engineering team must determine whether the relevant environment and device behavior match before treating the document as an applicable purchasing requirement.
An original analogy helps. Two people can both know a language but still disagree about the format of a shipping address. A shared form reduces ambiguity, but it does not prove the parcel reaches the right building. Likewise, a profile can reduce configuration mismatch without proving the physical timing result. The analogy stops at that boundary; it is not a claim that network synchronization is as simple as filling out a form.
The line's proposed equipment matrix consequently includes more than a checkmark. It identifies the exact supported behavior, the firmware used in the evaluation, the test partners, and any conditions under which a device changes roles. It also records what was not tested. A blank field is less reassuring than a green check, but a truthful blank can prevent an unsupported integration decision.
Compatibility is particularly easy to overstate after a successful two-device demonstration. A pair can work while the larger topology introduces a different path, load or administrative boundary. The proposed acceptance process therefore treats the pair test as a milestone rather than a conclusion. The point is not to make success impossible to recognize; it is to say precisely which uncertainty the successful test has removed.
A timestamp needs a place on the drawing
The fictional team now draws the route from physical change to saved record. The first box is the phenomenon. The next is the sensing mechanism, then any conversion or buffering, then the point at which time is associated with the event, then the software path and the stored record. Some devices may combine several boxes; others may distribute them across hardware and software. The drawing describes functions rather than insisting on one architecture.
At each boundary, the team asks whether the time represents occurrence, detection, reception or processing. Those labels can all be legitimate. Trouble begins when the label silently changes. A record of when a server received a message is not automatically a record of when the remote sensor observed the event. If the application needs reception time, the first label is exactly right. If it needs physical event time, further evidence is required.
Suppose Instrument A attaches time at detection while Instrument B attaches time after a queue. In the toy example, B's queue varies between zero and four units. If the analyst subtracts the two timestamps without including that variation, an apparent delay between instruments may partly describe the queue. The analysis might then attribute a software behavior to the material being tested. That is a category error even if both clocks are excellent.
This drawing also clarifies what a correction can accomplish. A stable, measured delay may be accounted for in a model, with its remaining uncertainty. An unpredictable component cannot simply be erased by subtracting its average and declaring the result exact. The residual variation still matters, especially when the question concerns individual events rather than a long-run mean.
For reporting, the proposed rule is to keep the measurement-point label beside the number. Readers should not need to search an appendix to discover that the headline result concerned a network interface while the application consumed a software timestamp. Clear labeling protects both the buyer and the supplier: it avoids crediting a component with a promise it never made, and avoids blaming it for uncertainty introduced elsewhere.
The clock can be steady and wrong
Repeatability and closeness to a reference are different properties. The fictional line illustrates this with two invented instruments. One stays consistently four units late. Another has no average bias over the test but wanders between positive and negative errors. Which is better depends on the task, the correction model and the tolerated uncertainty. A single adjective such as precise cannot settle that decision.
A graph of the errors would reveal more than a single average. The first instrument's stable offset could be visible and potentially characterized. The second might look excellent when its positive and negative errors cancel, even though individual event ordering remains uncertain. Conversely, a worst observed value alone does not describe how often the error occurred or whether the test duration was representative.
The team proposes reporting the observation duration, operating conditions, reference arrangement and distribution summary together. If a maximum is given, it is labeled as the maximum observed during that test, not a universal bound. If a percentile is given, the denominator and exclusions are stated. If an uncertainty interval is given, its meaning is explained rather than assumed from the familiar shape of a plus-or-minus sign.
This is also where resolution can mislead. A display that prints a timestamp in very fine increments may still have a much coarser uncertainty in its relationship to the event. Resolution is useful for representing values; it does not manufacture knowledge. The proposed article figure therefore uses invented uncertainty bands rather than a decorative clock with an exaggerated number of digits.
A skeptical reader need not reject every impressive result. The right response is to ask which property was measured. A stable local relationship can be extremely valuable. So can an externally traceable relationship with a larger uncertainty. The problem is not that one is secretly worthless; it is that a decision can require a different property from the one being advertised.
White Rabbit is evidence, not a magic label
Some research systems pursue exceptionally fine timing through a tightly specified combination of hardware, frequency distribution and delay treatment. A 2011 conference paper by Grzegorz Daniluk and Tomasz Wlostowski describes the White Rabbit PTP Core and reports measurements for a five-kilometre single-mode fibre connection. Its abstract distinguishes offset from precision and describes active delay compensation. This is primary evidence about a particular design and experiment, not a promise for an arbitrary Ethernet network. Daniluk and Wlostowski.
A later author preprint by Ben Amies-King and Marco Lucamarini, submitted in November 2025, reports White Rabbit synchronization across a three-hundred-kilometre single-span optical fibre link. The opened author abstract describes careful endpoint component selection and optimization. The publisher page was not readable during this research, so the discussion here is explicitly based on that preprint abstract, not a claim to have inspected the complete journal version. Amies-King and Lucamarini.
The two studies are useful precisely because they are specific. Their distance, arrangement and performance statements belong together. Removing the arrangement and retaining only an impressive unit would weaken the evidence. Our fictional line should not assume that a demonstration on a selected optical link transfers unchanged to its own mixed equipment, environmental conditions and software measurement points.
This does not make the experiments irrelevant to practical engineering. It changes their role from blanket warranty to informed possibility. They show that ambitious timing performance can be investigated and demonstrated under described conditions. The next question for a different application is what must be preserved, measured or redesigned to support its own claim.
There is a broader communication lesson here. A technology name can become shorthand for a whole stack of assumptions. Once that happens, the name may circulate farther than the evidence. A responsible longread should unpack the stack instead of repeating the strongest number as if every product carrying the label inherits it automatically.
Losing the reference is a state, not an embarrassment
A system designed only for the moment when everything is working has not yet described its operational behavior. The fictional line needs to know what its clocks do when their controlling reference is unavailable, how the loss is detected, and how applications learn that the timing claim has changed. Continuing to display time is not the same as continuing to meet the previous uncertainty statement.
NIST's glossary defines holdover as an operating condition in which a clock has lost its controlling reference and uses its local oscillator, potentially augmented by information acquired while locked or by a frequency reference. That is a description of a state, not a duration guarantee. A device's usable holdover interval depends on its characteristics and the application's tolerance. NIST holdover definition.
Consider a simplified illustrative model with a constant frequency error of one part per million. Over one thousand seconds, the accumulated time error would be one millisecond, before accounting for other effects. This is arithmetic for a hypothetical oscillator, not an assertion that any particular product behaves that way. Temperature changes, aging and initial uncertainty can make a real holdover model more complicated.
The example nevertheless exposes an important application question. A clock does not become either perfectly correct or utterly useless at the instant its reference disappears. Its uncertainty may grow, and different tasks may cross their tolerances at different times. A slow trend analysis might remain useful while a fine event-order comparison should be marked uncertain. The application needs a meaningful state signal rather than a silent continuation of the old label.
The team's proposed record format therefore preserves the timing state alongside the event. It does not erase data merely because the reference was lost, nor does it automatically accept that data for every analysis. It allows later users to decide what can still be inferred. This is an editorial proposal for evidence preservation, not a universal implementation requirement.
Redundancy must name the shared dependency
Two clocks are not necessarily two independent sources of assurance. They may depend on the same external service, antenna, power supply, software implementation or administrative change. If the purpose of redundancy is to survive a particular failure, the design needs to show that the supposed alternatives do not share that failure in a hidden way.
For the fictional line, imagine two reference boxes connected to separate ports but powered by the same unprotected outlet. The visible network diagram shows duplication; the failure diagram shows a common dependency. Now imagine separate power but a shared upstream timing source. The second arrangement addresses one concern while leaving another. Calling either arrangement redundant without naming the intended threat is incomplete.
NIST's January 2023 Foundational PNT Profile is a voluntary risk-management framework for organizations using positioning, navigation and timing services. Its official abstract explicitly includes natural and manufactured, intentional and unintentional disruptions or manipulations. The page also carries a March 2025 planning note about alignment with a newer cybersecurity framework; that note is not treated here as proof that a replacement publication had already been completed. NIST IR 8323 Revision 1.
The original practical implication for our example is to draw dependencies by function, not by box count. Which component establishes the reference? Which transfers it? Which measures disagreement? Which reports the state to the application? If the monitoring path depends on the same failed component as the measured path, a reassuring dashboard may be less independent than it appears.
A good dependency drawing can also prevent waste. The team may discover that a modest change to monitoring independence answers its actual concern better than buying another high-specification clock. Or it may discover that a genuine alternate reference is necessary. The drawing does not dictate the purchase; it makes the reason for the purchase testable.
Authentic messages can still arrive late
Timing security has a distinctive complication: the arrival time of a message can matter even when its contents remain intact. Authenticating the sender and protecting the message against alteration are valuable, but they do not by themselves establish that every relevant delay is known. A valid message can travel through an unexpected path or experience an unusual wait.
RFC 7384, published in October 2014 as an informational document, separates security requirements for time protocols, including integrity, authentication, availability and protection against delay manipulation. It discusses the relationship between security mechanisms and network topology rather than claiming that one cryptographic feature solves every timing threat. Its requirements analysis is not a deployment recipe or evidence that all products implement those protections. RFC 7384.
A 2024 research paper, available as an author manuscript marked accepted at INFOCOM, proposes PTPsec using cyclic path-asymmetry measurements over redundant paths. Its abstract reports a hardware-testbed evaluation of specified delay-attack scenarios. Those claims describe the authors' evaluated design, not universal immunity for ordinary PTP installations. Only the author abstract was used here; no instructions for attacking a live timing system are supplied. PTPsec author manuscript.
For the fictional line, the legitimate defensive question is how a suspicious disagreement becomes visible and what operational response has been approved. It is not enough to collect security features in a checklist if nobody knows which application assumptions should change when timing confidence falls. The response might preserve records, flag uncertainty or enter an engineering-defined operating state. The appropriate action depends on the installation's hazard analysis and authorized procedures.
This is a place to resist dramatic language. An unexplained timing discrepancy is not proof of an attacker. It can arise from ordinary faults, changed paths, configuration mistakes or environmental effects. Investigation should preserve alternatives rather than letting the most alarming explanation win by default. Defensive preparedness and evidential restraint reinforce each other.
Management data is part of the evidence
A timing installation can be physically sophisticated and still be difficult to investigate if its configuration history is missing. Analysts need to know which reference was selected, which settings were active, when changes occurred and whether the state shown in a dashboard corresponds to the interval being examined. A screenshot taken after an incident may not describe the system during it.
RFC 8575, published in May 2019, defines a YANG data model for configuring and retrieving information and running states from PTP clocks based on IEEE 1588-2008. Its scope is specific; it is not a claim that one model covers every later feature or technology-specific profile. The document provides a primary example of treating configuration and state as structured information rather than informal notes. RFC 8575.
The fictional team's proposed evidence package includes configuration identity, software and firmware versions, the measurement-point description, and a record of timing-state transitions. It also includes the assumptions behind any corrections applied to timestamps. If a later analysis subtracts a fixed offset, the original timestamp and the correction history remain recoverable. Otherwise, a well-intentioned repair can erase the information needed to evaluate that repair.
Access control matters here for an ordinary reason: changing the reference or the interpretation of time can affect many downstream records. The people authorized to alter timing configuration should not be inferred from whoever can edit a convenient dashboard. The article does not prescribe a specific permissions system; it identifies an administrative boundary that should be explicit.
Documentation also needs a retirement path. When an instrument is replaced, its calibration context should not vanish with the old hardware. A historical dataset may remain valuable long after the original clock is gone. Preserving its timing meaning is part of preserving the measurement, just as preserving units is necessary to keep a column of numbers interpretable.
The test should challenge the claim it supports
Original hypothetical bounded-error example, prepared 1 November 2026. A: 97–103, B: 101–107 overlap; C: 105–111 lies wholly later than A. Invented time units; not observed data or a universal uncertainty interpretation.
The fictional line's first proposed experiment is deliberately modest: compare a clearly defined event record against an independent reference under a documented, representative condition. The aim is not to stage the most dramatic disturbance. It is to establish what is actually being measured before expanding the test matrix. Testing that could affect live equipment belongs in authorized engineering procedures, not an improvised production experiment.
The next proposed tests vary one relevant condition at a time where possible. That helps distinguish an effect from an uncontrolled combination of changes. If the claim includes performance during a transition, the transition should be observed rather than inferred from steady-state behavior before and after it. A system that eventually recovers can still produce an important interval of uncertainty while recovering.
The report should also preserve unsuccessful measurements and exclusions. Suppose a test produces one hundred records, but ten arrive without a usable timing-state label. Reporting excellent accuracy for the remaining ninety is not false if the selection is stated. It becomes misleading if the result is presented as though all one hundred were covered. Missingness can be part of the operational performance, not just an inconvenience to the analyst.
For an invented uncertainty example, let Event A have a recorded time of one hundred units with a bound of three units in either direction, and Event B a recorded time of one hundred and four with the same bound. A could lie between ninety-seven and one hundred and three; B between one hundred and one and one hundred and seven. The intervals overlap. The four-unit difference in displayed timestamps does not, under these assumptions alone, establish their true order.
If B instead appears at one hundred and eight with the same bounds, its earliest allowed time is one hundred and five, later than A's latest allowed time of one hundred and three. Under this simplified bounded-error model, the order is resolved. Real uncertainty statements may not be hard bounds, and correlated errors require additional care. The example teaches the question to ask, not a universal statistical rule.
The incident report should allow an unresolved answer
Return to the fictional vibration investigation. The team initially wants a simple sequence: current changed, then motion changed, therefore one caused the other. Better timing could help establish order, but order alone would still not establish causation. A third process might influence both measurements. A control command might precede both without being included in the dataset. A timing audit can repair one part of an explanation without proving the rest.
This is why the proposed incident report separates observations, corrections and interpretations. Observations include the recorded values and the state information available at the time. Corrections include explicitly documented adjustments supported by calibration or another stated model. Interpretations describe what those records suggest about the process. Keeping those layers separate makes disagreement more productive: a reviewer can accept the observations while questioning a correction, or accept both while proposing a different causal explanation.
An unresolved ordering should remain unresolved rather than being settled by the number of digits in a spreadsheet. The report can say that the events were too close to distinguish under the measured timing uncertainty. That conclusion is not a failed investigation. It identifies what the available evidence can support and helps define a more informative future experiment. Forcing a sequence from inadequate evidence can send maintenance effort toward the wrong component.
The same discipline applies when an event disappears during a reference transition. An analyst should distinguish no event from no usable observation. A gap in the record may have several explanations, and filling it by interpolation could hide the very transition under investigation. If interpolation is useful for a separate trend display, the derived values should remain distinguishable from measurements in the preserved record.
There is also a human handoff problem. A new analyst may inherit files without the engineer who understood their timing conventions. The proposed package therefore includes a short plain-language account of what each timestamp means, not only a machine-readable schema. A schema can say that a field contains a time value; the accompanying explanation should say whether it marks detection, receipt or processing, and how changes in timing state affect interpretation.
Finally, the report should identify the decision that actually depends on tighter timing. If the maintenance choice would be identical across every plausible ordering, an expensive improvement may not be necessary for that choice. If different orderings imply different interventions, the unresolved interval becomes a meaningful engineering requirement. This connects the measurement budget to a real decision rather than rewarding precision for its own sake. It also gives the public-interest reader a sensible test of a technology claim: what can people conclude or do more responsibly because this timing evidence is better?
What the next purchase should prove
The most useful purchase request from the fictional line would not simply demand more decimal places. It would describe the event, the required comparison, the acceptable uncertainty and the conditions under which that claim must hold. It would ask suppliers to identify the measurement point behind their performance figures and to separate demonstrated behavior from supported options that have not been evaluated in the proposed installation.
A second request would concern change. What happens after a firmware update, a replacement cable, a reference change or a different application timestamping path? Not every alteration requires the same level of retesting, but the decision should follow a documented understanding of which assumptions changed. A calibration result is evidence about an arrangement, not a permanent property that floats above the arrangement.
A third request would concern communication to the people using the data. Can the system express that timing confidence has changed without requiring an analyst to infer it from an obscure maintenance log? Can a dataset retain the distinction between measured event time and later processing time? Can a reader discover the reference and uncertainty without knowing the original engineer personally?
These requests are demanding in a useful way because they align spending with inference. Better timing can enable sharper questions about a physical process, more defensible comparisons across instruments and more intelligible investigations. But those benefits arise when the timing information reaches the decision with its meaning intact. A highly capable component hidden inside an ambiguous data path cannot do that work alone.
The factory clock, in this sense, is not one box on a wall or one service on a network. It is a chain of evidence connecting a physical event to a recorded claim about when it happened. The chain becomes trustworthy through explicit boundaries, measured uncertainty, preserved state and honest reporting of failure. Precision matters. Knowing precisely what was measured matters just as much.
Evidence and publication note
Prepared on 1 November 2026 from the linked primary sources. This is an original explanatory synthesis, not a deployment specification or professional safety assessment. Author-abstract-only access is identified in the relevant passages. Historical findings are not presented as current universal performance. All research-line events and numerical exercises are explicitly hypothetical. No live configuration, publication or indexing is performed.