Hacker News new | ask | show | jobs
by sdsaga12 1575 days ago
This had been my impression of PTP too, and I think in many circumstances it's true, but I recently listened to this episode from Jane Street's Signals and Threads podcast that gave some interesting explanation of why they chose to base their synchronization system on NTP: https://signalsandthreads.com/clock-synchronization/

Preview: "Yeah. I think that’s roughly the conclusion I came to, that that’s what makes PTP more accurate than NTP, which was surprising to me. And then I did a bunch of research and was talking to various people in the industry, and at various conferences and stuff, and there was some agreement that you can make NTP also very accurate you just have to control some of these things, so there are… in addition to being able to do hardware timestamping with PTP packets some cards, these days, support the ability to hardware timestamp all the packets, and if your machine is just acting as an NTP server and most of the packets it receives are NTP packets, well then you’re effectively timestamping NTP packets. Some cards also will timestamp just NTP packets. They can sort of recognize them and timestamp only those, but it was sort of like “Okay if we have the right hardware, we can get the timestamping bit of it. That’s kind of an interesting thing. With the different NTPD implementation, chrony being the other implementation I’m talking about as opposed to the reference one, you can turn that knob for how frequently you should poll your server, I think as much as like 16 times a second. There’s a bit of like diminishing returns there, it’s not always better to go lower… point being, you can tune it to at least match sort of what PTP’s default of once a second.

And the more I dug, and the more I talked to people, the more people told me, “Hey, you definitely do not want to involve your switches in your time distribution. If you can figure out a way to leave them out of it, you should do so.” I was happy to hear that in some ways, because right now the reliability. or the sort of, the responsibility of the time distribution kind of lies with one group, and that’s fine. When you then have this responsibility shared across multiple groups, right, it becomes a lot more complicated. Every switch upgrade, suddenly, you’re concerned. “Well, Is it possible that this new version of the firmware you’re putting on that version of that particular switch has a bug related to this PTP stuff and is causing problems?”

Given all of that, I started to believe that it was possible that we could solve this problem of getting within 100 microseconds using NTP and I sort of set out to try and see if I could actually do that."

1 comments

My familiarity with PTP is in the context of distributed embedded systems, sometimes using the PTP hardware for relative synchronization without even having an absolute reference; but in that world, PTP precision is an order or magnitude or two better than "within 100 microseconds" -- 1 us is a sane target, and 5 us is very comfortable.
For what it’s worth, we normally aim for < 50 nanoseconds RMS on our systems with PTP. You can get even better if you combine it with synchronous Ethernet.