TL;DR
- ▸Lucky packet filtering extracts precision time from a noisy WAN PTP stream by selecting the fastest packets and weighting them more heavily.
- ▸The intuition is that the fastest packets approximate the true minimum network delay; the slower packets are dominated by transient queueing and contribute noise.
- ▸Right tool for shared WAN links where the operator doesn't control the infrastructure end to end.
The intuition
PTP measurements over a noisy network produce a distribution of round-trip delays — most packets are delayed by transient queueing, congestion or scheduling jitter, but a few packets get through with minimum delay because they happened to arrive at the switch when the queue was empty. The fastest packets in any measurement window approximate the true minimum network delay between the master and slave clocks. The slower packets are dominated by transient noise and contribute error rather than information.
Lucky packet filtering uses this observation to extract a precision time estimate from the fastest few packets in each measurement window, ignoring the noisy majority. In practical deployments this can extract microsecond-class precision from a network where naive PTP would deliver tens of microseconds.
When to use it
Lucky packet filtering is the right tool for WAN-distributed PTP where the link is shared with other traffic and individual packet delays vary significantly. It's not magic — the achievable precision is bounded by the lowest-jitter packets the filter can find — but it's the best available technique when the operator doesn't control the WAN infrastructure and can't engineer for symmetric paths.
Common use cases include precision time distribution across a third-party transport network, multi-site deployments where the inter-site connectivity is leased rather than owned, and any deployment where lucky packet filtering is the only way to extract microsecond-class precision from a link that's shared with general traffic.
What it can't do
Lucky packet filtering can't deliver sub-nanosecond precision. The achievable precision is bounded by the minimum network delay variability, which on most WAN links is in the low microseconds. For applications that need sub-nanosecond precision over long distances, White Rabbit on operator-controlled fibre is the right answer.
Where TimeBeat fits
TimeBeat's PTP grandmaster implementations support lucky packet filtering for slave clocks operating across WAN links, and the Sync Insight observability platform tracks the filter's performance continuously so the operator can verify the precision is meeting the deployment's budget. For customers running multi-site deployments across shared WAN links, the conversation about whether lucky packet filtering meets the precision requirement is one we have regularly.
Frequently asked questions
What is lucky packet filtering?+
How precise can lucky packet filtering get?+
Is lucky packet filtering a substitute for symmetric fibre engineering?+
Related reading
Blog · WAN timing
How to Achieve Sub-Microsecond Accuracy Over Wide Area Networks
Distributing precision time over a wide area network — between data centres, regions, or continents — is fundamentally harder than distributing it across a single LAN. What the techniques actually look like in 2026.
Blog · White Rabbit
Why White Rabbit is Changing the Game for Finance, AI and Quantum Innovation
White Rabbit — the sub-nanosecond fibre-distributed timing protocol developed at CERN — is moving out of physics labs and into financial trading floors, AI training clusters and quantum networking testbeds. What it actually does, and why precision below one nanosecond is now a commercial requirement.
Blog · Standards
Understanding IEEE 1588 PTP: How Precision Time Powers Industrial Ethernet
What IEEE 1588 actually defines, how the protocol works at the message level, and why it's the foundation under every modern industrial Ethernet, telecom and broadcast timing fabric.