You have a timing requirement to meet. A supplier quotes a nanosecond figure, your PTP software shows a small offset, and the devices report that they are synchronized. Can you sign off the system?
Not from those three facts alone. Before you compare numbers, you need to know what was measured, where it was measured, and which reference was used. A clock can look stable in its own diagnostics while your camera exposure, controller output or event timestamp still misses the required time.
This guide helps you turn a Precision Time Protocol accuracy claim into testable evidence—without confusing a protocol feature, a laboratory result and your installed application’s performance.
How accurate is Precision Time Protocol in practice?
PTP can support sub-microsecond synchronization, and suitably designed implementations can go substantially further. But IEEE 1588 does not give every PTP-capable device or network the same accuracy guarantee. Your result depends on the reference clock, timestamping, network path, endpoint, configuration and measurement method. The IEEE 1588-2019 overview describes this implementation-dependent capability.
For your project, replace “high-precision PTP” with a requirement you can test:
The measured time error at [defined output or event], relative to [defined reference], must remain within [limit] during [specified operating conditions and observation period], using [agreed measurement method and decision rule].
For example, “within ±1 µs at the endpoint PPS output, relative to the grandmaster PPS output under the agreed network load” is meaningful. It still needs a test duration, sampling plan and uncertainty statement, but it already says far more than “1 µs PTP accuracy.”
Four PTP accuracy numbers you should not compare as equals
The first question to ask about a timing number is simple: Which layer does it describe?
| Number you see | What it tells you | What it does not prove |
|---|---|---|
| Timestamp resolution, such as a 1 ns increment | How finely a timestamp can represent time | That its value is within 1 ns of the reference |
| PTP-reported offset | The servo’s estimated clock offset, using its timestamps and delay model | An independently measured error at your output or application |
| Independently measured time error | The difference between a specified DUT output and a specified reference, subject to measurement uncertainty | Performance at a different output, under a different load, or outside the observed interval |
| Application-event timing error | When the event you care about actually occurs or is timestamped | That every other application event or operating condition behaves the same way |
Resolution and accuracy are different concepts in the International Vocabulary of Metrology. A finely divided ruler can still have its zero in the wrong place. A finely resolved timestamp can have the same problem.
Likewise, the offset statistics reported by tools such as LinuxPTP are useful diagnostics. They help you spot loss of lock, excursions and configuration problems. They are not independent evidence that the output is correctly aligned: the reported value still depends on the system’s own timestamps and assumptions about delay.
PTP accuracy relative to what: the grandmaster, another device or UTC?
Before choosing an instrument, define the reference. These are three different requirements:
- Grandmaster-relative alignment: How far is your endpoint from the selected grandmaster?
- Device-to-device alignment: How far apart are two cameras, controllers or measurement units?
- UTC-referenced accuracy: How far is your output or event from UTC through a documented traceability chain?
If two devices share the same clock error, they may agree closely with each other while both are wrong relative to UTC. Conversely, two endpoints each within ±1 µs of the same reference could be as much as 2 µs apart in the worst case. Measure the pair directly when the pairwise requirement is what matters, preferably simultaneously.
For UTC-referenced acceptance, your reference’s uncertainty and traceability belong in the evidence. “GNSS locked” is a status indication, not the complete uncertainty statement. The BIPM’s UTC information explains the reference timescale; your test still needs a documented route from that timescale to the actual measurement point.
Also record the timescale and UTC-offset/leap-second handling where relevant. A clean PPS phase comparison alone does not establish that the correct second or date is being labelled.
Why your PTP synchronization accuracy changes
You do not need to redesign the entire network to audit an accuracy claim. Start with the places where an apparently small offset can hide a larger error.
Hardware timestamping reduces variation—not every source of error
Software timestamps can include variation from the operating system and packet-processing path. Hardware timestamps taken closer to the MAC or PHY can reduce that variation. However, the timestamp location, fixed input/output delays, endpoint servo and calibration still matter. The Linux networking timestamping documentation distinguishes these timestamp paths.
Ask where the timestamps are generated and which delays have been compensated. “Hardware timestamping supported” is not a numerical end-to-end guarantee. Nor does one-step versus two-step operation, by itself, tell you whether timestamping is hardware or software based.
Unequal forward and reverse delay can bias the result
PTP estimates clock offset using a delay model. In the usual two-way calculation, if the model assumes equal forward and reverse delay but their actual difference is Δ, the resulting offset estimate is biased by Δ/2, subject to the calculation’s sign convention and other corrections being correct.
A hypothetical 200 ns forward-minus-reverse mismatch therefore contributes a 100 ns bias to that estimator. This is an illustration, not a prediction for your fiber or switch. The IEEE high-accuracy profile material discusses asymmetry and its correction. Check how your implementation defines its asymmetry parameter: some parameters already represent the half-difference, so you must not halve it again.
Your investigation may need to include transceivers, different fiber paths, PHY delays and direction-dependent traffic—not only the number of switches.
A synchronized clock is not necessarily a synchronized action
An endpoint’s hardware clock may be aligned while an application reads another clock, queues an event or waits for an operating-system task. Output circuitry and camera exposure timing can introduce further delay and variation.
If your requirement concerns an exposure, a PLC output or a timestamped input, that is the acceptance point. A clock-register value or PPS result can support the investigation, but it cannot replace the relevant event measurement.
How to test PTP accuracy independently
Use three levels of evidence. Each answers a different question; you do not need to pretend that one measurement covers them all.
1. Use endpoint diagnostics to find problems
Record the selected grandmaster, lock state, reported offset, path delay and relevant counters. Preserve the configuration and version information with the logs.
Diagnostics can show when something changed. They are especially useful for correlating timing excursions with a load change or clock-selection event. Keep them alongside the independent measurements, not in place of them.
2. Compare accessible clock outputs through a separate measurement chain
If your reference and endpoint provide suitable, documented PPS outputs, you can compare their edges with a suitable calibrated time interval counter. A suitably characterized oscilloscope may serve some requirements, but it is not automatically adequate for a nanosecond-level claim.
Before collecting data, agree on these details:
- Reference planes: For example, the two devices’ specified PPS output connectors. Include the relationship between the clock and those outputs; unknown output delay is not zero delay.
- Signal settings: Compatible voltage, impedance, termination, edge polarity and trigger threshold, following the equipment documentation.
- Measurement-chain corrections: Cable-delay difference, channel skew, fixed output delays and relevant instrument corrections. Equal cable lengths alone do not prove equal electrical delay.
- Instrument capability: Calibration status, timebase, resolution, noise and the uncertainty appropriate to your limit.
- Epoch and sign: Which edge represents which second, which channel is the reference, and whether positive time error means that the DUT is ahead or behind.
Define your reported quantity explicitly, for example TE(t) = T_DUT(t) − T_reference(t). Translate the instrument’s start/stop convention into that definition. Apply justified corrections and include the remaining uncertainty. Do not subtract an unexplained “typical delay” to make the result pass.
3. Measure the application event when that is your requirement
For a camera system, you may need to compare exposure-active signals or another validated exposure measurement. For a controller, you may need to compare the specified physical output or timestamped input with the reference event.
Document any sensor, probe or acquisition delay. If you cannot access an appropriate output, agree on another validated observation method with the equipment supplier. Report what it actually measures; do not rename a software log “application accuracy.”
Test the conditions your installation will actually see
An idle bench test is a useful baseline, not complete acceptance evidence. Keep a separate result record for each agreed condition:
| Condition | What to preserve in the record |
|---|---|
| Baseline after defined warm-up | Topology, firmware, profile, timing mode, reference and endpoint settings |
| Representative production load and expected peaks | Traffic rate, packet sizes, burst pattern, direction, relevant QoS configuration and port utilization |
| Relevant temperature or supply conditions | Actual measured conditions and stabilization time—not only the product’s rated range |
| Required topology or clock-selection changes | Event timestamp, excursion window, missing samples, and separate steady-state versus transition criteria |
Record test duration, sample interval, sample count, invalid or missing samples, filtering and any discarded warm-up period. A PPS measurement at one sample per second cannot rule out every excursion between those samples. Choose a method and observation rate that can see the behavior your requirement is intended to limit.
There is no universal “test for ten minutes” rule. Your duration should be long enough to exercise the agreed operating conditions, cycles and events. State the limit of the evidence: it describes the observed test, not every future second of operation.
Reading a PTP accuracy report: mean offset is not maximum time error
Suppose a report gives a small mean and a narrow standard deviation. That is useful, but it does not tell you the largest observed error—and it is not a hard guarantee.
| Reported statistic | How you should read it |
|---|---|
| Signed mean | Average bias; positive and negative errors can cancel |
| Standard deviation | Variation around the mean, not the absolute error limit |
| RMS time error | Combined effect of bias and variation, not the largest excursion |
| Maximum absolute time error | Largest observed magnitude under the stated sampling and test conditions |
| 99th or 99.9th percentile | A tail statistic; some samples can exceed it |
For a useful real example, NIST Technical Note 2030 reports a particular PTP PPS comparison through two transparent clocks. Over an observation exceeding 3,600 seconds, that configuration produced a mean of 17 ns, standard deviation of 6 ns, minimum of −2 ns and maximum of 36 ns. The observed maximum absolute value was therefore 36 ns—not the 17 ns mean.
Those results belong to NIST’s stated reference, calibrated measurement arrangement, profile and configuration. They are not a limit for all PTP networks, a Maisvch result or automatically a UTC-referenced claim. The example shows why you need the method and statistics together.
If your contract specifies metrics such as MTIE or TDEV, request those metrics using the prescribed procedure. A convenient mean or percentile is not a substitute.
Use measurement uncertainty in your PTP accuracy acceptance decision
A reading close to the limit is not automatically a pass. The uncertainty of the measurement also matters. The VIM definition of measurement uncertainty describes the dispersion of values attributable to the measured quantity; it is not just the number of digits on the instrument.
For a teaching example, assume you agree on:
- A symmetric limit of ±1.00 µs at the specified output.
Mas the maximum observed absolute corrected time error in the agreed record.- An applicable expanded uncertainty
U = 0.12 µs, with coverage factork = 2; the uncertainty model, coverage interpretation and applicability to the reported metric are documented. - One conservative decision rule: pass if M + U ≤ the limit; fail if M − U > the limit; otherwise report indeterminate.
| Illustrative M | M − U to M + U | Outcome under this agreed rule |
|---|---|---|
| 0.62 µs | 0.50 to 0.74 µs | Pass: the upper value remains within 1.00 µs |
| 0.94 µs | 0.82 to 1.06 µs | Indeterminate: the interval overlaps the limit |
| 1.18 µs | 1.06 to 1.30 µs | Fail: even the lower value exceeds the limit |
These are invented teaching values, not Maisvch test results. This is one possible agreed guard-band rule, not an IEEE 1588 requirement. It does not turn uncertainty into a certain error bound or guarantee unsampled behavior. For a real acceptance plan, agree the decision rule and acceptable decision risk before testing; JCGM 106 provides the relevant conformity-assessment framework.
If your uncertainty or a required correction is unknown, the evidence is incomplete. Do not enter zero and call the result compliant.
What accuracy evidence should you request from a PTP switch supplier?
Send the supplier a requirement and an evidence request, not just “Do you support IEEE 1588?” Use this checklist to make different proposals comparable.
| Ask for | Why you need it |
|---|---|
| Measured quantity, limit, reference and reference plane | To establish whether the number concerns the clock, PPS output or application event |
| Exact models, hardware revisions and firmware/software | To know which configuration the evidence covers |
| PTP profile, clock roles, transport, delay mechanism and message settings | To confirm that the tested timing arrangement matches your design |
| Timestamp location and delay/asymmetry corrections | To identify what the implementation measures and compensates |
| Complete topology, endpoints, optics and link details | To avoid treating a direct-cable result as a multi-hop result |
| Traffic, environment, warm-up, duration, sampling and missing-data handling | To understand what operating conditions were exercised |
| Independent method, instruments, calibration and uncertainty | To distinguish an output measurement from a diagnostic screenshot |
| Raw or suitably detailed results, statistics and decision rule | To judge excursions, traceability and the actual acceptance outcome |
When you evaluate a PTP Ethernet switch, check the documented role and compatibility for your exact model. A protocol listing alone does not prove a particular boundary-clock or transparent-clock implementation, profile, PPS output or end-to-end error limit.
For example, the MISCOM8216PTP-4XGF-4GF-8GT provides a DIN-rail option, while the MISCOM8030PTP-6XGF-16GF-8GC provides a rack-mount option. Their documentation lists IEEE 1588v2 PTP and IEEE 802.1AS gPTP. Use that to start a model-specific technical discussion—not to infer an unqualified nanosecond accuracy guarantee.
Request timing test evidence from Maisvch: share your reference source, endpoint models, topology, PTP profile and required time-error limit. Ask which configuration is supported and what evidence is available for those exact conditions. Where evidence is missing, agree on a sample verification plan before acceptance.
Questions to settle before you accept a PTP accuracy claim
Does a stable PTP offset mean my system meets a ±1 µs limit?
No. It means the reported estimate is stable under the conditions observed. You still need to check its reference, possible bias, independently measured output or event, uncertainty and test coverage.
Can I verify nanosecond accuracy with an ordinary oscilloscope?
Not from its displayed resolution alone. You need adequate channel timing performance, suitable signal settings, calibration, corrections and an uncertainty analysis for the measurement. If those cannot support your limit, use a more capable measurement arrangement or a qualified timing laboratory.
What if my endpoint does not provide PPS?
First identify another documented output or event that represents the timing requirement. You may be able to compare an exposure signal, hardware trigger or timestamped acquisition against a suitable reference. If only diagnostics are accessible, label them as diagnostic evidence and state what remains unverified.
Is nanosecond PTP accuracy possible across any Ethernet network?
No. Achievable accuracy belongs to a complete, specified implementation and measurement setup. Validate the actual reference, profile, clock roles, links, endpoint and operating conditions. A nanosecond-resolution field or a result from another topology is not enough.
