How Does NTP (Network Time Protocol) Work?
sookocheff.com
sookocheff.com
[0]http://www.articlesfactory.com/articles/computers/using-wwvb...
I live in an area without decent WWVB reception. So one of these days, my plan is to build a house range WWVB antenna so that I can get all the radio clocks in my house working consistently.
One of the products I've been impressed by recently is a GPS receiver and PTP master built into an SFP connector [1]. No affiliation with the company, but a super simple way to get a local GPS-disciplined PTP source into a network.
[1] https://www.oscilloquartz.com/en/products-and-services/ptp-g...
[1] https://www.realtek.com/en/products/communications-network-i...
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."
This is why pairing PTP and NTP together gives you a result that is better than either of them alone. PTP makes a great Stratum 0 reference clock for NTP, which can then apply higher level protocols along with other information source inputs to synthesize a higher quality time source that can then be made publicly available.
And this is also why the Network Time Foundation [1] publicly supports both protocols.
Disclaimer: I've been a member and supporter of the public NTP project since 2003, as well as associated projects like the NTF.
[1]: https://pallen.ece.gatech.edu/Academic/ECE_6440/Summer_2003/...
Not commonly discussed but I wrote a script to do Chrony added configuration to mitigate this.
https://github.com/egberts/easy-admin/blob/main/480-ntp-chro...
The article mentions network delay filtering algorithms that fall in broad categories x and y, but doesn't mention what NTP actually uses (linking to some pdf presentation elsewhere). Then there's a section about clock selection (which I understand to mean server selection) where it sounds like clocks are selected at random, no matter if they're on another continent, it's just favored if it has a low stratum. Then NTP talks to up to 5 servers and averages the resulting clock diff and, uh, applies that "using the PLL/FLL clock control system". This refers to some phase lock loop stuff from what earlier seemed to be a tangent: how quartz clocks work internally. So NTP actually tells the hardware to adjust how fast it counts? That sounds like I'd have heard of before but okay. If the offset is large and it's not enough to slow down or speed up your internal quartz for a time, it'll instead just update the time.
The TL;DR seems to be this picture: https://sookocheff.com/post/time/how-does-ntp-work/assets/nt...
Where you can understand "selection and clustering algorithms" to mean "removing outlier data points" and substitute "combining algorithm" with "average the values". The abbreviation VFO is never mentioned on the page but this must be variable frequency oscillator, commonly referred to as "clock" -- if I understood it correctly. What this "filter" is, that is applied to each peer, is unclear to me.
Which... I know editing Wikipedia is hard, because of the moderators, but if you think you can do better than a given Wikipedia article, please consider just fixing the Wikipedia article.
"It uses the intersection algorithm, a modified version of Marzullo's algorithm, to select accurate time servers and is designed to mitigate the effects of variable network latency."[0][1]
It works as long as all your uplinks aren't too slow or too fast...
Variable latency means sometimes there's extra delay, and is solved by throwing away measurements that are outside the norm. Assymetry in delay is not handled by the reference implementation, which assumes equal delay to and from each server.
Say Bob assumes the round-trip is symmetrical and adjusts his local time to the time Alice sends minus half the round-trip time, then any asymmetry should be visible as a consistent offset between the local time and the time from Alice no?
This of course assumes the latency and local clocks are relatively stable over the measurement period.
I did make an Excel sheet but clearly I dun goofed. Too late for math!
To put it another way, you can't distinguish being in sync and Bob -> Alice taking 4 ms, and Alice -> Bob taking 6 ms, from being out of sync by 1 ms, and both directions taking 5 ms.
If you've got an external reference, such as GPS or an adjusted for time in transit radio clock, you can figure this out. If you've got a asymmetric first hop, but afterwards a mostly symmetric path (common for residential customers connecting to commercially hosted ntp servers) and a set of servers that are different round trips away, you can get an estimate. But if all the servers are the same/similar round trips, you likely won't have enough information.
The thing is, it's rather difficult to determine the individual components of the path latency without an out of band reference clock. Especially if all of your network clocks are about the same round trip away.
I found especially the last part with some hints on how to correctly measure time passed when doing manual profiling helpful (by not using the wall clock, but the monotonic clock. Probably everybode else knows this, but I didn't :D).