Rendered at 12:28:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
MiracleRabbit 5 hours ago [-]
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.
NkVczPkybiXICG 14 hours ago [-]
Why does the title say 1ns but the body of the article says 30ns (with hopes to eventually get it down to 5)?
geerlingguy 13 hours ago [-]
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).
rcxdude 1 hours ago [-]
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).
larpingscholar 13 hours ago [-]
It's the period of the carrier wave (900MHz)?
ectospheno 3 days ago [-]
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.
Youden 15 hours ago [-]
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.
geerlingguy 14 hours ago [-]
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!).
hdgvhicv 2 hours ago [-]
TC are fine for the typical number of devices at home, and are very cheap.
simoncion 9 hours ago [-]
> 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.
MiracleRabbit 5 hours ago [-]
The NICs need supported hardware timestamping. Then they can be used with ptp4l.
Intel i210 and i226 does this. But the i226 has a few variants.
simoncion 4 hours ago [-]
> The NICs need supported hardware timestamping.
Yes. I'm aware. Perhaps I'm more stupid about this topic than normal, but it looks to me like the NICs I have do (NIC names have been changed for clarity, but all other output is untouched):
$ ethtool -T intel-nic
Time stamping parameters for intel-nic:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
Hardware timestamp provider index: 0
Hardware timestamp provider qualifier: Precise (IEEE 1588 quality)
Hardware timestamp source: MAC
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
$ ethtool -T brcm-nic
Time stamping parameters for brcm-nic:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
Hardware timestamp provider index: 0
Hardware timestamp provider qualifier: Precise (IEEE 1588 quality)
Hardware timestamp source: MAC
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
ptpv1-l4-event
ptpv2-l4-event
ptpv2-l2-event
jcelerier 13 hours ago [-]
out of dozens of laptops and computers we have where I work, we have maybe 3 that have a PTP-compatible NIC.
CyborgCabbage 59 minutes ago [-]
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.
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.
bigfatkitten 11 hours ago [-]
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.
Lammy 10 hours ago [-]
I would rather not know the exact time than be spied on.
wildzzz 9 hours ago [-]
It's not for you. It's for a broadcasting team so all of the wireless camera feeds are properly synced.
lefra 5 hours ago [-]
In what situation would nanosecond accuracy be needed between cameras? Millisecond accuracy should be enough to get camera feeds in sync, even when looking at videos frame by frame.
bigfatkitten 3 hours ago [-]
To ensure each camera is scanning the same line of each frame at the same time.
This aids in switching without tearing, and if you’re using things like LED video walls, you want to synchronise the refresh rate of the video wall to the camera’s scan rate to eliminate “rolling” and other horrible visual artifacts.
lefra 3 hours ago [-]
Thanks, I didn't think synchronizing the pixel clock would be needed, but this makes sense.
ssl-3 2 hours ago [-]
That's a really good question. I hope I'm able to answer it.
The closer multiple sources of video can come to showing up at exactly the right time, in lockstep with eachother, the less need there is for buffers at any step.
When buffers are reduced at any step, latency is reduced at each of those steps.
When latency is reduced, it accumulates slower as steps are added, removed or different workflows are switched in and out.
And that makes getting continual coherency between processing workflows easier, instead of harder. Easy is good, innit?
---
There's other ways to get it done, but tight clocks are a Keep It Simple, Stupid method. The tighter, the better.
And, sure: I hear you. There's usually just 60 frames per second, or ~16ms per frame.
But video isn't necessarily a sequence of fixed frames like film is. It's (still!) often rasterized as scanlines, even just to transmit it from a camera to the next stage.
We can therefore process video as scanlines, instead of individual frames. We can switch between them and even mix them together without even buffering a whole frame first.
Or at least: We can do this if the clocks are tight-enough so that the lines themselves show up at the right time.
And that's useful: If we can get rid just 1 frame worth of input buffer and 1 frame of output buffer at a given step, then we save 2 frames worth of latency for that step, or ~32ms. That's 32ms that we don't need to figure out how to compensate for elsewhere, but we can only get there if the video sources (eg, live cameras) are tightly synchronized.
With 4k60 video, we get new raster lines at a rate of around 65KHz. That's not seeming like a very fast rate, but it's beyond the rate of integer milliseconds and well into the realm where microseconds are a better unit.
---
"So, fine. Microseconds can make sense. Why nanoseconds, then?"
With nanosecond resolution, it may be possible to go beyond clocking individual scanlines and can clock individual pixels instead.
"But seriously. Nanoseconds?"
Sure. Why not?
Maybe we can eventually get to the point where all this latency malarkey that got introduced with the transition from analog to digital signalling just ceases to matter. We didn't need framebuffers or jitter control or anything like that in strictly-analog world. That wasn't an issue at all.
Analog signals went in one end, and came out the other without any deliberate delay. Signals were switched and mixed without delay. Overlay graphics were inserted without delaying the signal they were overlaid upon. The (limited) processing we had occurred without delay. There was no frame judder because there wasn't enough complexity to introduce frame judder. We didn't have to consolidate different system latencies because we didn't have system latencies to consolidate. It was a simpler time.
With tight-enough clocks, perhaps we can get back to that kind of simple flow while maintaining the rote precision of working in digital number-land.
reed1234 10 hours ago [-]
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.
PowerElectronix 13 hours ago [-]
I think it only needs the travel time of the signal, but it's not well explained.
wiradikusuma 7 hours ago [-]
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?
Youden 5 hours ago [-]
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).
Matumio 6 hours ago [-]
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.
itishappy 7 hours ago [-]
A quartz oscillator drifts by roughly a second per day.
(Edit: Bad math left my underestimating by a few order of magnitude. Whoops.)
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.
1ns is about the best you can do with the nearly 1 GHz carrier (as mentioned in a sibling comment).
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.
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.
Intel i210 and i226 does this. But the i226 has a few variants.
Yes. I'm aware. Perhaps I'm more stupid about this topic than normal, but it looks to me like the NICs I have do (NIC names have been changed for clarity, but all other output is untouched):
> 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.
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.
This aids in switching without tearing, and if you’re using things like LED video walls, you want to synchronise the refresh rate of the video wall to the camera’s scan rate to eliminate “rolling” and other horrible visual artifacts.
The closer multiple sources of video can come to showing up at exactly the right time, in lockstep with eachother, the less need there is for buffers at any step.
When buffers are reduced at any step, latency is reduced at each of those steps.
When latency is reduced, it accumulates slower as steps are added, removed or different workflows are switched in and out.
And that makes getting continual coherency between processing workflows easier, instead of harder. Easy is good, innit?
---
There's other ways to get it done, but tight clocks are a Keep It Simple, Stupid method. The tighter, the better.
And, sure: I hear you. There's usually just 60 frames per second, or ~16ms per frame.
But video isn't necessarily a sequence of fixed frames like film is. It's (still!) often rasterized as scanlines, even just to transmit it from a camera to the next stage.
We can therefore process video as scanlines, instead of individual frames. We can switch between them and even mix them together without even buffering a whole frame first.
Or at least: We can do this if the clocks are tight-enough so that the lines themselves show up at the right time.
And that's useful: If we can get rid just 1 frame worth of input buffer and 1 frame of output buffer at a given step, then we save 2 frames worth of latency for that step, or ~32ms. That's 32ms that we don't need to figure out how to compensate for elsewhere, but we can only get there if the video sources (eg, live cameras) are tightly synchronized.
With 4k60 video, we get new raster lines at a rate of around 65KHz. That's not seeming like a very fast rate, but it's beyond the rate of integer milliseconds and well into the realm where microseconds are a better unit.
---
"So, fine. Microseconds can make sense. Why nanoseconds, then?"
With nanosecond resolution, it may be possible to go beyond clocking individual scanlines and can clock individual pixels instead.
"But seriously. Nanoseconds?"
Sure. Why not?
Maybe we can eventually get to the point where all this latency malarkey that got introduced with the transition from analog to digital signalling just ceases to matter. We didn't need framebuffers or jitter control or anything like that in strictly-analog world. That wasn't an issue at all.
Analog signals went in one end, and came out the other without any deliberate delay. Signals were switched and mixed without delay. Overlay graphics were inserted without delaying the signal they were overlaid upon. The (limited) processing we had occurred without delay. There was no frame judder because there wasn't enough complexity to introduce frame judder. We didn't have to consolidate different system latencies because we didn't have system latencies to consolidate. It was a simpler time.
With tight-enough clocks, perhaps we can get back to that kind of simple flow while maintaining the rote precision of working in digital number-land.
In this case it is only figuring out the distance from the other receivers for time synchronization and not positioning you on the globe.
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 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.
(Edit: Bad math left my underestimating by a few order of magnitude. Whoops.)
https://en.wikipedia.org/wiki/Clock_drift