Scope, Use-Cases, and “What Good Sync Looks Like”

This page is strictly about time infrastructure for CCTV: IEEE-1588/PTP with hardware timestamps, jitter-cleaning PLL/DPLL for clean clocks, and RTC hold-up for time continuity during outages. It does not cover PoE power allocation, surge devices, camera imaging/ISP, or NVR/VMS platform design.

“Good sync” in CCTV is not only about being close to an absolute time source; it is about being consistent across devices and auditable under real network load, temperature drift, and power events. The engineering target must be expressed in measurable metrics that can be verified in production tests and field diagnostics.

Three measurable success metrics

Timing Metrics & Error Budget for Video/Events

CCTV timing design fails most often because requirements are expressed as “PTP on/off” rather than a measurable time error budget. A budget converts the system goal (alignment, correlation, forensics) into four practical contributors that can be engineered and verified: Network PDV, Timestamp path, PLL/DPLL residual jitter, and Oscillator/temperature/holdover drift.

Metrics that matter (and how they show up in the field)

“Most damaging” depends on which symptom must be prevented: jitter/PDV dominate under congestion, drift dominates over hours with temperature gradients, and holdover error dominates whenever the reference disappears (link/GM/power events).

Error budget: split the total time error into controllable contributors

An actionable budget turns “sync quality” into a set of engineering levers: reduce PDV exposure, move timestamps into hardware, attenuate jitter with DPLL, and choose an oscillator/RTC holdover strategy that matches outage and temperature realities.

• Network PDV contribution: queueing and path variation; mitigated by PTP-aware switching (BC/TC) and traffic isolation (principle only).
• Timestamp path contribution: if timestamps occur above the MAC/PHY boundary, software scheduling noise creates long-tail errors.
• PLL/DPLL residual contribution: loop bandwidth and lock strategy determine how much wander is passed vs filtered.
• Oscillator + temperature + holdover contribution: TCXO/OCXO grade and thermal environment set the stability ceiling during outages.

Acceptance statement templates (copy into test plans)

• Steady-state: PHC offset to GM is ≤ X (95th percentile) and ≤ Y (max) over a Z-minute window under normal load.
• Stress / congestion: Under defined traffic stress, 95th percentile offset remains ≤ X, and the maximum does not exceed Y, with no backward time jumps.
• Holdover: After loss of reference, time error stays within X for 10 min holdover and within Y for 30 min; device logs enter_holdover / exit_holdover markers with timestamps.

PTP/IEEE-1588 in CCTV: Minimal Protocol View (Only What You Need)

This chapter intentionally avoids “PTP textbook depth”. It focuses on the smallest protocol view that directly supports CCTV engineering: which messages move which error terms, and what to verify in packet captures to prevent “PTP enabled but still unstable” deployments.

What Sync/Follow_Up changes (and what it cannot fix)

• Sync / Follow_Up are the “time sampling” path: they deliver timing information used to estimate current offset. Under congestion, variable queuing delay (PDV) can inflate the long-tail of offset even when the average looks fine.
• If cameras show occasional misalignment spikes, suspect the offset distribution tail, not the mean. A stable CCTV timeline must be written in percentiles (e.g., 95th) and worst-case bounds, not averages.

What Delay mechanism changes (and why PDV matters)

• Delay_Req / Delay_Resp (or peer-delay in some designs) estimates path delay. Any error or variation in this estimate feeds directly into offset and increases sensitivity to network load.
• PDV is the practical enemy: as network load rises, queueing variability can distort both the Sync sampling and Delay estimation, creating the exact symptom CCTV integrators hate: “mostly aligned, but occasionally wrong.”

Domain / priority / GM selection: practical meaning in CCTV

• Domain answers “which time universe is this device following?” A domain mismatch can produce large pairwise skew across cameras even if each camera claims it is “locked”.
• Priority & GM selection define time authority and failover behavior. Frequent GM changes can look like “random jitter” in offset; the cure is policy + logging: record GM changes and correlate them with offset spikes.
• For CCTV, the most important property is often consistency across endpoints and auditability, not raw absolute accuracy.

Packet capture checklist (minimum evidence)

Hardware Timestamping: Where the Timestamp Must Live

In CCTV deployments, PTP failures are often misdiagnosed as “protocol issues”. A more common root cause is simpler: timestamps are generated too high in the software stack, so OS scheduling, interrupts, and queueing create long-tail time errors. The result is the classic symptom: “PTP looks locked, but multi-camera alignment still slips.”

Where “HW timestamp” can live (and how to judge it)

• PHY-based: timestamp unit close to the physical interface; strongest isolation from software jitter.
• MAC/NIC-based: timestamp at transmit/receive boundaries (still wire-adjacent) and exposed via PHC.
• SoC-integrated Ethernet: can be valid HW TS if timestamping occurs at the Ethernet controller boundary, not inside an OS timestamp API above the driver.

Why “looks synchronized” but cameras still misalign

• Tail-driven slips: mean offset is small, but rare spikes break alignment. This is typical when timestamps are taken in software after queueing/scheduling delays.
• Load sensitivity: alignment degrades only when many streams run or when CPU load is high. That pattern is a strong indicator of software-path timestamp noise.
• Hidden time domains: camera-to-camera skew can remain large if devices follow different domains or unstable GM (validated in H2-3 via domainNumber and GM behavior).

HW TS vs SW TS: the A/B proof every project should run

Switch Participation: Boundary Clock vs Transparent Clock (Practical Implications)

In CCTV deployments, the switch layer often determines the synchronization ceiling. Protocol packets can look correct while alignment still fails because network PDV (packet delay variation) inflates the long tail of offset and skew. Switch participation (TC or BC) is the practical mechanism that prevents “multi-hop + mixed traffic” from turning into random timeline slips.

Transparent Clock (TC): what it fixes in practice

• A TC does not become a new clock authority. It forwards timing messages while writing path corrections (e.g., residence/forwarding time) into the packet’s correctionField.
• Practical impact: TC reduces how much multi-hop forwarding variability expands the offset tail. This is especially important when a CCTV network has multiple aggregation hops.
• What TC does not solve: a severely congested uplink can still produce PDV large enough to break tails. TC helps, but it cannot create bandwidth or eliminate queueing at saturation.

Boundary Clock (BC): when it becomes necessary

• A BC terminates the timing loop at the switch and runs a local servo, then re-originates timing downstream. This effectively segments the network and prevents upstream PDV from freely propagating through all hops.
• Practical impact: BC improves scalability and can make tail behavior predictable on large CCTV deployments. It also provides clearer “lock state” boundaries for auditing and debugging.

If switches are not PTP-aware: how to prove PDV is the bottleneck

The goal is to distinguish “network-limited” vs “endpoint-limited” synchronization using evidence that is repeatable and audit-friendly.

Clock Tree Inside Devices: PHC, Local Oscillator, and Distribution

PTP delivers timing information over the network, but an endpoint only becomes “sync-capable” when it can turn that information into a usable, low-noise clock and timebase inside the device. The internal clock tree is the bridge between PHC (hardware time), the local oscillator, and the clocks consumed by media pipelines and event logic.

PHC vs system clock vs media clock: separation goals

• PHC (PTP Hardware Clock): the time authority used by the PTP servo and used for time stamping and audit logs. It should stay stable and measurable (offset/skew percentiles).
• System/CPU clock domain: a noisy domain affected by DVFS, bus contention, interrupts, and scheduling. It should not be allowed to inject noise into timing-critical domains.
• Media/trigger clock domain: time-critical clocking for frame timing, encoder pacing, or event I/O alignment. This domain benefits from jitter-cleaned clocks and controlled distribution.

Clean clock vs recovered clock: which modules need which

Evidence pattern that points to internal clock-tree coupling

• Offset mean remains stable, but 95th/max grows when CPU/video load increases.
• Pairwise skew grows under device load even when network conditions are unchanged.
• PTP capture fields look normal (domain/sequence/correction), yet alignment still slips: this shifts suspicion to internal distribution and clock cleanliness.

Jitter-Cleaning PLL / DPLL: How to Choose and Tune

In CCTV timing systems, “locking” is not the finish line. The real requirement is staying stable when network load, hop count, and endpoint activity change. A jitter-cleaning PLL/DPLL sits between a noisy time reference and the clocks consumed by media and event correlation. The objective is to reject short-term noise while keeping long-term error bounded and recovery behavior predictable.

Loop bandwidth: what it controls (and why “smaller” is not always better)

Loop bandwidth is the main knob that decides how much the output follows the input reference versus the local oscillator. It directly trades off noise rejection and correction speed.

Holdover: who dominates the error when the reference is gone

• While disciplined: output stability is dominated by reference noise (PDV, switch behavior) and loop filtering strategy. The loop decides how much to “trust” the network reference.
• In holdover: error is dominated by the local oscillator (temperature drift, aging) and its environment. At that point, “good filtering” cannot compensate for an unstable timebase.
• At reference return: the servo strategy must prevent abrupt time steps and provide predictable convergence. Stability is measured by both transient shape and tail behavior after re-lock.

Acceptance measurements: choose one primary set and make it repeatable

For CCTV deployments, a practical acceptance method is to use offset distribution tails and a recovery curve under representative traffic. This directly maps to multi-camera alignment and auditability.

Holdover Timebase: RTC + Hold-Up Power + Temperature Reality

For CCTV evidence, the most damaging failure is not small drift — it is time discontinuity (time jumps, time going backward, or undefined gaps across power loss and reboot). Holdover design defines how a device preserves time continuity when power or reference timing is disturbed, and how it restores timing without breaking auditability.

RTC vs monotonic time: roles and boundaries

• RTC (wall time): preserves an approximate real-world time reference across power loss, enabling “close to correct” restoration. RTC accuracy is often temperature-dependent.
• Monotonic time: guarantees that local time used for ordering events never goes backward. Even if wall time is imperfect, monotonic continuity protects audit trails and sequencing.
• PTP/PHC re-discipline: aligns wall time back to the network reference after recovery while avoiding abrupt steps that break correlation.

Hold-up power goals: define duration and drift budget (not just hardware)

Hold-up power (supercap/battery) keeps the timing domain alive so the system can preserve continuity. But the error budget during holdover is dominated by RTC/oscillator drift and temperature reality, not by “capacity” alone.

Evidence test: power loss → power restore (the restore curve)

Holdover acceptance should be demonstrated with a repeatable “loss-and-restore” test: run disciplined, force a controlled outage (power or reference), wait for a defined duration, then restore and record offset vs time until it returns to steady-state tails.

Reference Options: GNSS, SyncE, and “When PTP Alone Isn’t Enough”

This section is a decision boundary (not a tutorial): choose the minimum reference stack that meets the long-term drift and audit requirements for CCTV timing. PTP can align endpoints very well inside a controlled network, but some deployments require a stronger long-term anchor or frequency discipline to maintain time continuity during long outages and harsh environments.

What each reference option primarily solves

When CCTV deployments must introduce external reference

• Long holdover targets: if the site must maintain bounded time error for long periods without network reference, external anchoring or stronger timebase becomes necessary (GNSS and/or better oscillator class, and/or frequency discipline).
• Cross-site evidence correlation: multi-location incident reconstruction and audit trails often require a common long-term anchor.
• Uncontrolled switching / unstable PDV: external reference improves long-term behavior, but does not “fix” queueing variability; network ceilings still require evidence-based diagnosis (tails vs load/hops).

Validation & Compliance Tests: How to Prove Sync Works

Synchronization must be proven with repeatable evidence, not assumptions. This section provides a minimum viable test SOP that works for both factory acceptance and field re-testing: capture protocol evidence, read endpoint timing state, and report results in tail statistics and restore curves.

Minimal toolset (enough to close the evidence loop)

• Packet capture: confirm timing domains and message behavior (domain/sequence/corrections) at the network edge.
• PHC / endpoint timing status: confirm hardware timestamp path and servo state (locked/holdover/restore).
• Logs + statistics: compute offset/skew distributions and store restore curves for audit and regression.

A single table that works for factory acceptance and field re-test

Each test below includes: condition → measurement → pass/fail language → what it proves. The same table can be used in production as a baseline and in the field for re-validation after network changes.

Field Debug Playbook: Symptom → Evidence → Isolate → Fix

This playbook is designed for field use: each symptom is closed with a minimal evidence loop. Every path starts with two measurements (fast, repeatable), then uses a discriminator to isolate the dominant contributor, and ends with a first fix (minimal change first). MPNs below are examples to guide BOM selection and replacement strategy.

FAQs (PTP Timing & Sync for CCTV)

These FAQs target long-tail field questions without scope creep. Each answer is evidence-based: one result metric (tails / drift / restore curve) + one locating evidence (capture fields / PHC servo state), followed by a minimal first fix and a jump back to the relevant chapter(s).