With GNSS+PPS and a hardware timer latch you can easily sync internal microcontroller timers to 2 to 3-digits nanoseconds against the global standard with a tightly controlled loop. But cannot get better than the PPS signal itself (roughly 30-100nS).
Everything below needs that a huge amount of engineering. CERN&friends developed the "White Rabbit" (https://ohwr.org/projects/white-rabbit/) system for this. This allows sub-Nanoseconds syncing of netwoked devices.
The 2nd revision of the hardware is 1ns in simulation, likely 5ns in real-world scenarios. The first revision of the hardware (which I saw at NAB) is more like 30ns (with 20ps jitter, I believe).
1ns is about the best you can do with the nearly 1 GHz carrier (as mentioned in a sibling comment).
The limit of a time sync protocol is not generally directly because of the carrier frequency. It can be a lot better or a lot worse depending on many other details. (E.g. the pulse per second from a GPS receiver can give time syncs down to nanoseconds).
That is cool. I use a gps NTP server on my home network and live with sub-millisecond time sync. I’d go PTP but the equipment is a bit too expensive if the only value add is better time sync and I don’t need additional bandwidth. Prices coming down would be nice.
What's expensive? PTP is widely supported on commodity hardware these days. I think most Intel NICs support it, quite a few Realtek and a lot of embedded stuff, down to even MCUs like STM32.
Even if you want a NIC with a stable oscillator or GPS inputs to act as a grandmaster, you can buy an E810 with the necessary hardware from eBay etc. for a few hundred or DIY something yourself much cheaper.
Switches that properly support PTP are expensive, at least for now.
You can achieve microsecond accuracy with a lot of non-timing-specific networking hardware, but it's around as good as you get with modern NTP...
To get sub-microsecond, you need hardware that supports transparent/boundary clock and doesn't just 'say' it does, but actually does (vendors have stamped PTP support on things that definitely don't account for time correctly internally!).
I have an Intel NIC (an Intel I211 using ixgbe) and a Broadcom NIC (BCM5719 using tg3) that claim to support PTP. I'm using the 802.11as profile on my LAN. These NICs are hooked up to Mikrotik CRS326-24G-2S+'s that also claim to support PTP.
Despite my neighbor switches reliably emitting Announce packets every second [0] the Intel NIC will -every few hours- fail to pass along three of those in a row to ptp4l, causing it to switch grandmaster mode for a few seconds before it recovers. The Broadcom NIC does this once or twice a day. These failures happen on both systems, regardless of system load. I've tried fiddling with a whole bunch of ptp4l settings to relax delivery timeouts, and it doesn't seem to help.
So, yeah, just because something claims to support PTP doesn't mean that it'll actually work well.
[0] I know this because packet capture during a couple of the incidents confirms this.
GNSS time is still cooler because you can have extremely accurate time and a reading of your position without the broadcasting satellites knowing you're there.
They’re comparing it to GPS which also uses multi-lateration (multiple measurements of time/distance) for positioning based off the known positions of satellites.
In this case it is only figuring out the distance from the other receivers for time synchronization and not positioning you on the globe.
When you drive through the Texas Pandhandle at night, squaremiles of electric windmills blink together – like fireflies stirring across flatlines of [L]one-star horizon.
They've been simultaneous for decades... and remains a breathtaking detour (if you're out there, schedule night-travel).
----
I like the similar project which uses GPS signal offsets, captured on a RaspberryPi, to then broadcast (e.g:) a local-network-timeserver.
I've wondered if you could have an array of "firecrackers", each timed very precisely, with perfect spatial knowledge of each, and synchronize their ignition to produce arbitrary shaped pressure waves.
Most clocks drift. If you've ever used a normal watch (not a smartwatch connected to a phone) or a battery powered clock, you may have noticed that you need to correct the time every month or so, as by that time, it's lost accuracy.
The problem is due to the quartz oscillators these devices use, which are the same ones we use in phones, computers etc., which have the same problem as a result.
You don't notice this because just about every network-connected device these days uses NTP or something similar to keep its clock constantly up to date, but the clock itself is still inherently inaccurate.
There are also other mechanisms to keep clocks in sync by the way. Some mains-connected devices keep time using the 50Hz/60Hz mains voltage. Various countries have radio broadcasts that devices can be used to keep time (DE, US and JP run them, I believe).
Why care about continuous sync? When I was in small robotics startup we had a separate motor controller driving each axis. A customers complained that the precision was getting worse after running for a few days non-stop. Guess what? Each axis had its own CPU clock based timer defining how long a segment should take. The difference is negligible but it accumulates over time. It was no issue for other customers who had a pause somewhere in their motion.
Why nanoseconds though? Usually a sub-microsecond sync is good enough. I can only think of some specialized phase measurements, really, like when you need to know from which direction a radio signal is coming based on timing of two antennas.
With GNSS+PPS and a hardware timer latch you can easily sync internal microcontroller timers to 2 to 3-digits nanoseconds against the global standard with a tightly controlled loop. But cannot get better than the PPS signal itself (roughly 30-100nS).
Everything below needs that a huge amount of engineering. CERN&friends developed the "White Rabbit" (https://ohwr.org/projects/white-rabbit/) system for this. This allows sub-Nanoseconds syncing of netwoked devices.
Wi-Wi uses the same principle as white rabbit to get sub-GPS-level sync.
Why does the title say 1ns but the body of the article says 30ns (with hopes to eventually get it down to 5)?
The 2nd revision of the hardware is 1ns in simulation, likely 5ns in real-world scenarios. The first revision of the hardware (which I saw at NAB) is more like 30ns (with 20ps jitter, I believe).
1ns is about the best you can do with the nearly 1 GHz carrier (as mentioned in a sibling comment).
The limit of a time sync protocol is not generally directly because of the carrier frequency. It can be a lot better or a lot worse depending on many other details. (E.g. the pulse per second from a GPS receiver can give time syncs down to nanoseconds).
It's the period of the carrier wave (900MHz)?
approximately, with assumptions.
Assuming ISM band in the US.
https://en.wikipedia.org/wiki/ISM_radio_band
That is cool. I use a gps NTP server on my home network and live with sub-millisecond time sync. I’d go PTP but the equipment is a bit too expensive if the only value add is better time sync and I don’t need additional bandwidth. Prices coming down would be nice.
What's expensive? PTP is widely supported on commodity hardware these days. I think most Intel NICs support it, quite a few Realtek and a lot of embedded stuff, down to even MCUs like STM32.
Even if you want a NIC with a stable oscillator or GPS inputs to act as a grandmaster, you can buy an E810 with the necessary hardware from eBay etc. for a few hundred or DIY something yourself much cheaper.
Switches that properly support PTP are expensive, at least for now.
You can achieve microsecond accuracy with a lot of non-timing-specific networking hardware, but it's around as good as you get with modern NTP...
To get sub-microsecond, you need hardware that supports transparent/boundary clock and doesn't just 'say' it does, but actually does (vendors have stamped PTP support on things that definitely don't account for time correctly internally!).
1 reply →
> I think most Intel NICs support it...
I have an Intel NIC (an Intel I211 using ixgbe) and a Broadcom NIC (BCM5719 using tg3) that claim to support PTP. I'm using the 802.11as profile on my LAN. These NICs are hooked up to Mikrotik CRS326-24G-2S+'s that also claim to support PTP.
Despite my neighbor switches reliably emitting Announce packets every second [0] the Intel NIC will -every few hours- fail to pass along three of those in a row to ptp4l, causing it to switch grandmaster mode for a few seconds before it recovers. The Broadcom NIC does this once or twice a day. These failures happen on both systems, regardless of system load. I've tried fiddling with a whole bunch of ptp4l settings to relax delivery timeouts, and it doesn't seem to help.
So, yeah, just because something claims to support PTP doesn't mean that it'll actually work well.
[0] I know this because packet capture during a couple of the incidents confirms this.
4 replies →
out of dozens of laptops and computers we have where I work, we have maybe 3 that have a PTP-compatible NIC.
> Wi-Wi stands for Wireless 2Way interferometry
> 2Way
Does that mean you won't get to know the time unless you let them spy on your physical location too? That's what the diagram implies: https://www.gps.gov/sites/default/files/2025-06/CGSICMeeting...
GNSS time is still cooler because you can have extremely accurate time and a reading of your position without the broadcasting satellites knowing you're there.
There are lots of situations where GNSS isn’t available, especially in broadcasting.
A live event in a convention center for example. You might have a truck outside with GNSS, but it’s blocked inside by the building.
I would rather not know the exact time than be spied on.
6 replies →
They’re comparing it to GPS which also uses multi-lateration (multiple measurements of time/distance) for positioning based off the known positions of satellites.
In this case it is only figuring out the distance from the other receivers for time synchronization and not positioning you on the globe.
I think it only needs the travel time of the signal, but it's not well explained.
When you drive through the Texas Pandhandle at night, squaremiles of electric windmills blink together – like fireflies stirring across flatlines of [L]one-star horizon.
They've been simultaneous for decades... and remains a breathtaking detour (if you're out there, schedule night-travel).
----
I like the similar project which uses GPS signal offsets, captured on a RaspberryPi, to then broadcast (e.g:) a local-network-timeserver.
I've wondered if you could have an array of "firecrackers", each timed very precisely, with perfect spatial knowledge of each, and synchronize their ignition to produce arbitrary shaped pressure waves.
I've wondered if something like this could ever be used for VR tracking, though it seems it is much bulkier in than IR methods.
Most important question: Is it pronounced Why-Why, or Wee-Wee?
Why not "Why-Wee"?
Maybe silly question, why we care about nanosecond speed, don't we only need to sync once and the other system can count the time by itself?
Most clocks drift. If you've ever used a normal watch (not a smartwatch connected to a phone) or a battery powered clock, you may have noticed that you need to correct the time every month or so, as by that time, it's lost accuracy.
The problem is due to the quartz oscillators these devices use, which are the same ones we use in phones, computers etc., which have the same problem as a result.
You don't notice this because just about every network-connected device these days uses NTP or something similar to keep its clock constantly up to date, but the clock itself is still inherently inaccurate.
There are also other mechanisms to keep clocks in sync by the way. Some mains-connected devices keep time using the 50Hz/60Hz mains voltage. Various countries have radio broadcasts that devices can be used to keep time (DE, US and JP run them, I believe).
Why care about continuous sync? When I was in small robotics startup we had a separate motor controller driving each axis. A customers complained that the precision was getting worse after running for a few days non-stop. Guess what? Each axis had its own CPU clock based timer defining how long a segment should take. The difference is negligible but it accumulates over time. It was no issue for other customers who had a pause somewhere in their motion.
Why nanoseconds though? Usually a sub-microsecond sync is good enough. I can only think of some specialized phase measurements, really, like when you need to know from which direction a radio signal is coming based on timing of two antennas.
A quartz oscillator drifts by roughly a second per day.
(Edit: Bad math left my underestimating by a few order of magnitude. Whoops.)
https://en.wikipedia.org/wiki/Clock_drift
Better signal penetration with Wi-Wi could be a game changer for battery life.
thats insane
lol to whoever downvoted me. i worked for months on wireless timing software for frame syncing displays and this had me speechless.