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.
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.
> 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.
[deleted]
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).
Assuming ISM band in the US.
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.
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.
In this case it is only figuring out the distance from the other receivers for time synchronization and not positioning you on the globe.
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.)
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):
$ 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-eventThe 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.