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).
It's the period of the carrier wave (900MHz)?
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 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.
out of dozens of laptops and computers we have where I work, we have maybe 3 that have a PTP-compatible NIC.
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?
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.)
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.
It's not for you. It's for a broadcasting team so all of the wireless camera feeds are properly synced.
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.
Most important question: Is it pronounced Why-Why, or Wee-Wee?
Why not "Why-Wee"?
Better signal penetration with Wi-Wi could be a game changer for battery life.
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).
It's the period of the carrier wave (900MHz)?
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 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.
out of dozens of laptops and computers we have where I work, we have maybe 3 that have a PTP-compatible NIC.
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?
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
> 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.
It's not for you. It's for a broadcasting team so all of the wireless camera feeds are properly synced.
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.
Most important question: Is it pronounced Why-Why, or Wee-Wee?
Why not "Why-Wee"?
Better signal penetration with Wi-Wi could be a game changer for battery life.
thats insane