TL;DR
- ▸Every PTP timestamp carries noise — network jitter, asymmetric delay, oscillator phase noise, GNSS multipath and host interrupt latency. Raw timestamps are unreliable for production applications.
- ▸TimeBeat's jitter attenuation engine processes these noisy inputs through multi-source filtering, adaptive servo control and statistical outlier rejection to produce a clean, stable clock output with sub-nanosecond residual phase noise.
- ▸This is the core differentiator of the TimeBeat software stack. The hardware captures the timestamps; the jitter attenuation engine makes them trustworthy.
Why raw PTP timestamps are not enough
A PTP grandmaster locked to GNSS produces timestamps that are, on average, within tens of nanoseconds of UTC. But individual timestamps are not averages — each one carries the noise of the entire measurement path: the GNSS receiver's multipath environment, the oscillator's short-term phase noise, the network's variable queueing delay, asymmetric forward and reverse path latencies, and the host operating system's interrupt scheduling jitter. A single PTP Sync message's timestamp can be off by hundreds of nanoseconds or more from the true time, even when the grandmaster's average accuracy is excellent.
For most monitoring dashboards this doesn't matter — the dashboard displays a smoothed view and the operator sees the average. But for applications that consume time directly — financial timestamping, broadcast frame alignment, 5G fronthaul radio coordination, distributed database consistency — the individual timestamp is what matters, not the average. A single anomalous timestamp can mis-order a trade, misalign a video frame, or cause a beamforming coordination failure. The application needs every timestamp to be clean, not just the mean.
This is the problem jitter attenuation solves. It takes the noisy raw timestamp stream from PTP, NTP and GNSS sources, filters it through a signal-processing pipeline, and produces a disciplined local clock output that is stable, accurate and trustworthy at every sample — not just on average over long windows.
The five noise sources that jitter attenuation addresses
Understanding what the attenuation engine is filtering requires understanding where the noise comes from. Five sources dominate the error budget in a typical production PTP deployment, and each has different statistical characteristics that require different filtering strategies.
- ●Network jitter. Variable queueing delay through switches and routers. Each PTP message experiences a different transit time depending on what other traffic was in the queue at the moment it arrived. The distribution is typically right-skewed — most packets are fast, but a tail of slow packets drags the mean. Boundary clocks reduce this hop-by-hop, but residual jitter remains, especially on the last hop to the slave.
- ●Asymmetric path delay. PTP assumes the forward and reverse network paths have equal one-way delay. When they don't — different fibre lengths, different switch internal architectures, different routing — the slave's offset estimate is systematically wrong by half the asymmetry. This is not random noise; it's a bias that doesn't average out. The attenuation engine has to detect and compensate for it.
- ●Oscillator phase noise. Every local oscillator — OCXO, DOCXO, rubidium — has short-term frequency instability characterised by its Allan deviation curve. This shows up as a random walk in the phase of the local clock. Good oscillators have lower phase noise, but all of them have some, and the attenuation engine has to distinguish oscillator noise from network noise to discipline the clock correctly.
- ●GNSS multipath and scintillation. The GNSS receiver on the grandmaster is exposed to multipath reflections from nearby structures, ionospheric scintillation during solar activity, and (increasingly) jamming and spoofing. Each of these produces errors in the GNSS-derived time that propagate through the PTP fabric. Multi-band, multi-constellation receivers help, but the attenuation engine is the last line of defence against GNSS-derived noise reaching the application.
- ●Host interrupt latency. On the slave side, the timestamp of a received PTP message includes the delay between the packet arriving at the NIC and the kernel processing the interrupt. On hardware-timestamped NICs this is small and consistent; on software-timestamped hosts it can be tens of microseconds and highly variable. The attenuation engine has to handle both cases.
Multi-source filtering: aggregating trust across references
The first layer of the attenuation engine aggregates timestamps from multiple independent time sources simultaneously. In a typical deployment, the agent receives PTP Sync messages from one or more grandmasters, NTP responses from backup time servers, and (where available) GNSS-derived 1PPS signals from a local receiver. Each source provides an independent estimate of UTC, and each estimate carries its own noise profile.
The multi-source filter cross-correlates these independent estimates to identify which sources are currently healthy and which are degraded. A grandmaster whose GNSS antenna has been obstructed will produce timestamps that drift relative to the other sources; the filter detects this divergence and reduces the weight of the degraded source before its noise contaminates the output. A network path that has developed asymmetric delay will produce a systematic offset relative to other paths; the filter detects and compensates for this.
The output of the multi-source filter is a single, weighted estimate of the current UTC offset and frequency error, with the contributions of degraded or noisy sources attenuated. This is fundamentally more robust than relying on a single PTP master — the filter provides resilience against individual source failures without requiring the operator to configure explicit failover logic.
Adaptive servo control: the loop that disciplines the clock
The servo loop is the core of the disciplining process. It takes the filtered offset and frequency-error estimates from the multi-source filter and uses them to steer the local oscillator toward UTC. The design of the servo loop determines the trade-off between tracking speed (how quickly the clock follows changes in the reference) and filtering quality (how much noise passes through to the output).
A fixed-bandwidth servo is a poor compromise. During stable GNSS lock, the reference is accurate and the servo should use a tight bandwidth — filtering aggressively, trusting the oscillator's short-term stability, and producing a very clean output. During holdover entry (when the reference is lost or degraded), the servo should widen its bandwidth to track the oscillator's free-run drift without overshoot. During GNSS re-acquisition after an outage, the servo should re-lock smoothly without introducing a step change that downstream applications would notice.
The TimeBeat servo is adaptive. It continuously estimates the noise characteristics of both the reference sources and the local oscillator, and adjusts the loop bandwidth in real time to optimise the trade-off for the current conditions. The result is a clock that is maximally filtered during stable operation and maximally responsive during transitions — without the operator having to configure anything.
Why this matters operationally
Fixed-bandwidth servos require the operator to choose between stability and responsiveness at configuration time. Get it wrong and the clock either over-filters during holdover (causing a step when GNSS re-acquires) or under-filters during stable operation (passing network jitter through to the application). The adaptive servo eliminates this choice by making it continuously and automatically.
Statistical outlier rejection: killing the bad packets
Before any timestamp reaches the servo, it passes through a statistical outlier rejection filter. The filter maintains a running model of the expected offset and delay for each PTP/NTP/GNSS source, based on the recent history of that source's measurements. Each new timestamp is scored against this model. Timestamps that fall within the expected distribution pass through; timestamps that are anomalous — typically because of transient network congestion, a queueing spike, or a corrupted GNSS measurement — are rejected.
The rejection is not binary. The filter assigns a confidence weight to each timestamp based on how closely it matches the expected distribution. Timestamps near the centre of the distribution get high weight; timestamps in the tails get reduced weight; timestamps far outside the distribution are rejected entirely. This soft-rejection approach is more robust than hard thresholds because it gracefully handles situations where the noise distribution changes (e.g., a network reconfiguration that shifts the baseline delay).
The combination of multi-source filtering and statistical outlier rejection means that the servo never sees the worst-case network noise. By the time a measurement reaches the disciplining loop, the most egregious outliers have been removed and the remaining measurements have been weighted by their reliability. The servo can then operate with a tighter bandwidth and produce a cleaner output than would be possible if it had to handle the full raw noise distribution.
Holdover-aware transitions: invisible to the application
One of the most operationally important aspects of jitter attenuation is how the engine handles the transition between disciplined operation (where a reference is available) and holdover (where the local oscillator is free-running). In a naive implementation, this transition produces a visible discontinuity — the clock's behaviour changes abruptly as the servo switches from tracking the reference to coasting on the oscillator. Downstream applications that are sensitive to rate-of-change in the clock offset (financial trading systems, broadcast frame aligners, distributed databases) can detect this discontinuity and react badly.
The TimeBeat attenuation engine makes holdover transitions application-transparent. As the reference source degrades (declining GNSS satellite count, increasing PTP message jitter, rising offset from the multi-source consensus), the adaptive servo gradually shifts its trust from the reference to the local oscillator. By the time the reference is fully lost, the servo is already operating primarily on the oscillator's free-run characteristics, and the transition from 'disciplined' to 'holdover' is a continuum rather than a step. The downstream application sees a continuous, smooth clock throughout.
The same principle applies in reverse during re-acquisition. When the reference returns after an outage, the servo re-locks gradually — steering the clock back toward the reference over a window that avoids any step change visible to the application. The operator can configure the re-acquisition aggressiveness, but the default is conservative: the clock re-locks within minutes, smoothly, without the downstream application noticing.
The result: sub-nanosecond residual phase noise
After multi-source filtering, statistical outlier rejection, adaptive servo control and holdover-aware transitions, the residual phase noise on the disciplined clock output is below one nanosecond RMS in steady state on hardware-timestamped deployments. This is the precision the downstream application actually receives — not the raw PTP offset (which can be tens or hundreds of nanoseconds of noise), but the attenuated, disciplined output that the signal-processing pipeline produces.
On software-timestamped hosts (where the raw noise floor is materially higher due to interrupt jitter), the attenuation engine still produces substantial improvement — typically 10-100× reduction in phase noise compared to the raw input. The absolute output precision is bounded by the host's timestamping capability, but the improvement relative to raw timestamps is consistent.
This is the core engineering differentiator of the TimeBeat software stack. The hardware captures the timestamps. The jitter attenuation engine makes them trustworthy. Without it, the precision of the grandmaster is wasted — the application receives noisy raw timestamps that carry the full burden of every noise source in the measurement path. With it, the application receives a clean, stable clock that it can rely on for every sample, not just on average.
Where TimeBeat fits
The jitter attenuation engine ships as part of the Timebeat Agent — the same binary that runs on every host in the timing fabric. It's not a separate product or an add-on; it's the signal-processing core of the agent itself. Every TimeBeat hardware product (Open TimeCard, Open Time Appliance, Open Time Appliance Mini, Open Time Node WR, White Rabbit Mezzanine) ships with the agent pre-installed and the attenuation engine pre-configured for the hardware's specific noise profile.
For deployments on third-party hardware (servers with Intel E810 or NVIDIA ConnectX NICs, for example), the agent's attenuation engine auto-detects the timestamping capability and configures itself accordingly. Hardware-timestamped deployments get the full sub-nanosecond residual noise; software-timestamped deployments get the best achievable improvement for their platform.