* High-speed stock trading, where regulations often require precise timestamping.
* Cell phone networks, where adjacent towers have to hold their frequencies precisely, and synchronise their transmit and receive time windows to avoid interference.
* Certain types of distributed database [1]
At a broader level, guarantees/specifications about NTP accuracy are hard to find. If you google 'NTP accuracy' you'll find a very wide range of claims, from sub-millisecond to >1 second [2]
Indeed, a lot of the NTP userbase has timing requirements so lax they can 'smear' a leapsecond [3] over the course of 24 hours, tolerating a sustained error of hundreds of milliseconds. They've got good reasons for doing it - but it goes to show big errors are possible even under normal, correct operation.
Therefore, if you have an application that needs single-millisecond-level accuracy, you won't find an NTP product specification saying it's what you want.
[1] https://en.wikipedia.org/wiki/Spanner_(database)#Architectur... [2] http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK [3] https://developers.google.com/time/smear
PTP enabled MAC's and PHY's usually have a dedicated hardware output for a PPS (pulse-per-second) or faster clock, generated directly from the hardware PTP counters.
In the video world, we get great results synchronizing software events with NTP, but whenever you jump to a physical interface (DisplayPort, HDMI, SDI, etc.), NTP-based clocks are far too jittery.
I've seen some work using the PTP hardware in the MAC with the NTP protocol, a sort of hybrid approach, but don't have any first hand experience.
- PTP is for sub-nanosecond local networks, with possibly hundreds of packets per second, local (in network card) clocks, hardware timestamping everywhere
- NTP if for long distance sync, with sophisticated statistical smoothing from several upstream servers
CERN uses PTP on steroids for physics experiments: https://white-rabbit.web.cern.ch/
Yes; satellite ground systems, satellite communications, earth observation
System time : 0.000084656 seconds slow of NTP time
Last offset : -0.000029673 seconds
RMS offset : 0.000046217 seconds
Frequency : 17.760 ppm slow
Residual freq : -0.001 ppm
Skew : 0.012 ppm
Root delay : 0.001419884 seconds
Root dispersion : 0.000967303 secondsCertain regulations in the financial industry lead you towards using it.
For example, Europe's MiFID II requires some systems to time stamp with 1 µs increments and 100 µs accuracy. PTP is the most common way to sync systems that have this requirement.
I've seen it used in projects for frame-accurate timing for IP video production (the use case was more TV studios than, say, Twitch streams)
Camera triggering/time stamping of frames that requires sub-millisecond accuracy, between multiple devices.
$ chronyc sourcestats
210 Number of sources = 7
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
PPS1 8 6 112 -0.018 0.020 -105ns 336ns
The other computers on the LAN have typically ~30uS std dev.
Our central NTP servers are getting, per "ntpq -c kerninfo", sub-millisecond error:
That's talking to a couple of Stratum 1, and a bunch of S2, servers.