Time Card and PTP on a Raspberry Pi Compute Module 4

    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 seconds

    $ 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

[1]: https://news.ycombinator.com/item?id=28372861

- 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

* 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

Certain 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.

Camera triggering/time stamping of frames that requires sub-millisecond accuracy, between multiple devices.

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)

CERN uses PTP on steroids for physics experiments: https://white-rabbit.web.cern.ch/

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.

Yes; satellite ground systems, satellite communications, earth observation

For professional setups, typically you'd have a coax going from the roof somewhere to the rack inside the data center where your time server is located.

I built a clock with a GNSS module and it gets enough of a signal by the window to keep time fine but I wouldn't rely on it.

The answer to that is "it depends".

Windows are known to work, but not all windows are made equal. Which direction your window is facing and whether you are in an urban canyon can make significant difference. Some windows also have films or coatings.

If you are working in tricky situations, then the quality of your antenna and the quality of your receiver will make a difference (e.g. multi-constellation support, interference mitigation, multipath rejection etc. etc.).

If you do not have access to a workable window, then your alternative options are:

   - Accept slightly lower accuracy and use LW radio instead (e.g. MSF, DCF etc.)
   - Rent a leased line to your country's national time laboratory. They will deliver you certified, traceable time with no roof access required and microsecond accuracy (backed by an SLA, i.e. accurate or your money back).
   - Run a long cable to the roof (if money is no object you can even get super fancy setups that run exclusively on fibre, no coax in sight)
   - Install an internal GNSS repeater system (still involves roof install, but gives you *much* more flexibility indoors for obvious reasons).

Imprecision in GPS (GNSS in general) solutions comes from a number of sources: Orbital errors in the satellite ephemerides, atmospheric distortions to the signal, multipath at the receiver antenna, and a bunch of minor stuff we're not gonna worry about. Those are the big three.

Orbital errors, you can't do anything about. Post-processing allows _position_ solutions to be corrected once the errors are known (a process that takes hours or days after the fact, to work back where the satellites must've actually been) in a process called Precise Point Solution, but that doesn't apply to [this kind of] timing.

Atmospheric errors you can kindof do something about. Signals from satellites lower to the horizon take a longer path through the atmosphere, so they tend to have wackier pseudoranges. Most timing-grade receivers have a default "elevation mask" of 15 or 20 degrees above the horizon, to simply not even bother with these crap signals, and derive timing only from what's left. (There are of course atmospheric models and corrections to apply, but these are applied to everything. Still, start with a cleaner signal and you'll end up with a cleaner result.) This means you need clear sky view to the middle of the sky, in order to raise the chances of an adequate number of satellites passing the elevation mask.

Multipath is huge. The reason survey-grade antennas have these enormous choke-ring structures around them is to eliminate multipath reflections off the surface of the ground below. Even cheap little antennas try to be more sensitive to signals from above than below, to limited success. (Especially if they're wrist-worn and thus not orientation-controlled. Ugh.) Any situation where the antenna is subject to multipath will have demonstrably worse precision as a result. So, most timing antennae are considerably elevated (gives the reflections an opportunity to fall apart), shielded (choke-ring mounts), or both. Cellular sites usually go with the elevation option since there's already a giant lightning-rod nearby, elevating the GPS antenna doesn't come with additional risk for the receiver.

Worse GPS reception means the receiver has a noisier signal to start with, and can't discipline its local oscillator as tightly. Even if you don't care about nanoseconds in the final application, you probably do care about _holdover performance_. And if your LO can be disciplined with nanosecond-accurate signals in the first place, it'll hold millisecond-accurate timing for days or weeks in a GPS outage. If the disciplining process is crap, the holdover will also be crap.