Is anyone using PTP and its requisite accuracy in production? If so, what's your use-case? Our central NTP servers are getting, per "ntpq -c kerninfo", sub-millisecond error: $ ntpq -c kerninfo associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, pll offset: -0.257641 pll frequency: 7.5157 maximum error: 0.165426 estimated error: 0.000422 […] That's talking to a couple of Stratum 1, and a bunch of S2, serv…
Any organization that requires nanosecond precision uses PTP. In my experience this usually includes financial exchanges that want to measure latency in trade routing.
Maybe a stupid question; if you're using GNSS as a time source, is it difficult to get reception? Do you have to put the receiver near a window or something? Or is it able to get signal even in cases where, for instance, my GPS watch would fail to get a lock?
> is it difficult to get reception? Do you have to put the receiver near a window or something? 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 whether you are in an urban canyon can make significant difference.
AIUI, urban canyons was one of the reasons why Japan built their QZSS system:
Maybe a stupid question; if you're using GNSS as a time source, is it difficult to get reception? Do you have to put the receiver near a window or something? Or is it able to get signal even in cases where, for instance, my GPS watch would fail to get a lock?
For non-professional setups, if you have a decent GNSS module/antenna then near a window works fine. 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.
Same. Mine is in a basement, and didn't get any reception with the included tiny antenna. Bought one of those active antennas shaped like a small puck, and place it near the ground-level window. Worked like a charm.
Is anyone using PTP and its requisite accuracy in production? If so, what's your use-case? Our central NTP servers are getting, per "ntpq -c kerninfo", sub-millisecond error: $ ntpq -c kerninfo associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, pll offset: -0.257641 pll frequency: 7.5157 maximum error: 0.165426 estimated error: 0.000422 […] That's talking to a couple of Stratum 1, and a bunch of S2, serv…
FWIW I posted some stats from my Raspberry Pi with a GPS module here[1] along with a VM on the same LAN. The tl/dr of the Pi:
$ 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.
Maybe a stupid question; if you're using GNSS as a time source, is it difficult to get reception? Do you have to put the receiver near a window or something? Or is it able to get signal even in cases where, for instance, my GPS watch would fail to get a lock?
One alternative would be to place the whole GNSS receiver outside and only run serial port and PPS signal from it (cat5 has just the right amount of pairs for RS-422 UART, RS-422 PPS and power. And is significantly cheaper than coax that is good enough for GNSS).
Maybe a stupid question; if you're using GNSS as a time source, is it difficult to get reception? Do you have to put the receiver near a window or something? Or is it able to get signal even in cases where, for instance, my GPS watch would fail to get a lock?
One alternative would be to place the whole GNSS receiver outside and only run serial port and PPS signal from it (cat5 has just the right amount of pairs for RS-422 UART, RS-422 PPS and power. And is significantly cheaper than coax that is good enough for GNSS).
Is anyone using PTP and its requisite accuracy in production? If so, what's your use-case? Our central NTP servers are getting, per "ntpq -c kerninfo", sub-millisecond error: $ ntpq -c kerninfo associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, pll offset: -0.257641 pll frequency: 7.5157 maximum error: 0.165426 estimated error: 0.000422 […] That's talking to a couple of Stratum 1, and a bunch of S2, serv…
PTP and NTP don't have the same use:
- 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
Is anyone using PTP and its requisite accuracy in production? If so, what's your use-case? Our central NTP servers are getting, per "ntpq -c kerninfo", sub-millisecond error: $ ntpq -c kerninfo associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, pll offset: -0.257641 pll frequency: 7.5157 maximum error: 0.165426 estimated error: 0.000422 […] That's talking to a couple of Stratum 1, and a bunch of S2, serv…
PTP and NTP don't have the same use: - 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
Basically, PTP assumes that network delays are deterministic. If that's true, it is very precise. If not, PTP is the wrong tool.
NTP assumes that network delays are stochastic, and uses sophisticated algorithms to account for this.
PTP has much simpler algorithms, which can be implemented in electronics, where internal timings can be characterized. NTP is more complex, and tends to run on a general purpose computer. This adds internal OS timings to the uncertainty.