"Father Time" Gets Another Year At NTP From Linux Foundation
dkatana writes: Harlan Stenn, Father Time to some and beleaguered maintainer of the Network Time Protocol (NTP) to others, will stay working for the NTP another year. But there is concern that support will decline as more people believe that NTP works just fine and doesn't need any supervision. NTP is the preeminent time synchronization system for Macs, Windows, and Linux computers and most servers on networks. According to IW, for the last three-and-a-half years, Stenn said he's worked 100-plus hours a week answering emails, accepting patches, rewriting patches to work across multiple operating systems, piecing together new releases, and administering the NTP mailing list. If NTP should get hacked or for some reason stop functioning, hundreds of thousands of systems would feel the consequences. "If that happened, all the critics would say, 'See, you can't trust open source code,'" said Stenn.
Nor can you trust closed-source code.
But while "open source makes all bugs shallow" is demonstrably a fallacy, at least you CAN see the source if you need to. (Good luck understanding it, though - says this pretty good C developer who just about shit when he had to look at OpenSSL/SSH code...)
With all due to respect to Harlan Stenn, and working under the assumption that he will choose to continue to maintain NTP for the good of everyone who uses it, the biggest donation that could possibly be given to the NTP project would be to increase its bus factor. Basically, we need at least another small handful of people -- ideally distributed throughout the world -- who have the same level of knowledge and expertise as Harlan in the area of network time, and can thus take his place if, for any reason whatsoever Harlan can't continue to work on the NTP project.
Getting Harlan to continue working on it is a short-term solution, but the sustainable future is to ensure that we have maintainers who can take his place -- ideally, paid ones.
So what we need is for a company like Red Hat or IBM or Microsoft or Canonical to bankroll a developer who has at least strong fundamentals that would enable them to quickly pick up advanced knowledge of network time, and then spend most of their working hours acquiring more knowledge about it so that it can be maintained going forward. This would probably involve a lot of ML posts with Harlan (or reading his previous ones), as well as any other developers/maintainers working on pieces of the code.
If Harlan is absolutely instrumental to the project as it stands now, the solution is to have a backup or two, who ideally are being paid a living wage to ensure the continuity of knowledge and expertise if Harlan willingly or unwillingly stopped contributing.
Projects with a bus factor of 1 that are widely relied upon need to be identified and highlighted every now and again -- not to make a case to shower the developer in money, but to get other developers to work in the same space and increase the bus factor to at least 3.
I got news for you; if NTP was non-free, it never would have been used outside of the lab where it was created. There would be 1000 competing network time sync strategies, Microsoft would blithely tell the whole world theirs is the best and universally compatible, while not actually being universally compatible with anything other than third-party malware, and it would be damned-near impossible for anyone without a Master's and 20 years of industry experience to succeed at establishing time synchronization across networks of machines supplied by a heterogeneous mix of OS and hardware vendors. You really want to take NTP and throw it in the same playpen where file-sharing and web-markup language standards got mangled? Really?
Poettering and the rest already have a time solution, why keep this old neckbeard around?
BSD NTP client - 3K lines of code. Linux NTP client - 192K lines of code. Guess which has fewer bugs.
Well, for starters, its not always drop-in compatible with existing clients and servers in the wild, and it lacks the necessary precision for doing any sort of work that that requires sub-second synchronization accuracy.
I'm assuming the 'BSD NTP client' is OpenNTPd. The 'Linux NTP client' is NTPd that we all know and is not linux specific.
Primary differences between the two:
OpenNTPd just cares about getting the local clock close to the remote NTP's supplied time. Nothing more.
NTPd wants to get the local clock as closely as possible to actual time as well as disciplining the local timesource such that 1 second is accurately 1 second, while weeding out faulty or maliciously bad sources of time. It also can act as a server, or as a peer in a server group. It can also directly interact with multiple reference clocks.
In short, you're comparing a simple client that just looks at the time on the wall vs something that's trying to be accurate and can act as the server side of the equation.
it's not just NTP that is languishing, perhaps a dozen other open source projects that the Internet depends on, each with one greybeard maintainer, underfunded or neglected entirely, going away soon, lose that institutional knowledge.
C'mon Apple, Google, Facebook, give back a little.
OpenNTPd added the ability to tweak the kernel tick rate to reduce skew. It can now keep your clock within 10 milliseconds between syncs. Still not as good as the official NTP.
A lot of it has to do with the fact that the system calls that you use to arrange time sync are, well, fragile and obscure and all-too-frequently broken by a new OS release. Also, a lot of bugs with respect to time synchronization are subtle and quick to anger and require quite a bit of time to reproduce and analyze.
In some ways, it would be a heck of a lot easier if we just forgot about stuff like having a monotonically increasing clock and clock skew caused by network latency. Just have everyone hard-set their clock every day from a GPS receiver, say. Of course, you'd end up with poor synchronization amongst hosts, which would easily cause its own kind of havoc. And your timestamps would be untrustworthy during that period where you are hard-setting the clock. There isn't a perfect solution.
7 days = 1 week
times 24 hours = 168 hours
Or in other words, he does not work in NTP 68 hours a week = 8.5h a day.
So considering that a person needs half an hour a day for eating, actually I eat longer, some sleep, some time on the toilet, some people even shower - shudder if that is longer than 5 mins - and usually you get dressed sometimes you have to go shopping ...
Well, I assume he is a nerd, sleeping in his bathrobe, so he saves dressing, showers only once a week and gets everything ordinary people shop via mail/internet order ...
Perhaps he should consider to hire an assistant? Or raise funds for one ... sorry: no one is working 100 hours a week.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
It's been able to do 10ms accuracy for around the last year after they added the ability to adjust the kernel tick rate.
Not particularly highlighted in the article is that the LF CII is funding a small team of developers with NTP experience to focus on security hardening, development process modernization, and opening the community. There is concern about the bus factor and an attempt is being made to address it.
No critical infrastructure project should ever be so dependent on a single developer.
Let's be clear here - we are talking about one particular software package - albeit a very popular one - and not the underlying protocol (which itself is subject to errata, some of which are still under discussion).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I don't keep up with Harlan's schedule these days, but I worked with him briefly back when he was at Netflix. At the time, he didn't strike me as much of a braggart or prone to exaggeration. And his work ethic was ... not high on work/life balance.
I wouldn't bet against him working that hard on NTP -- I've never before met anyone who loved a protocol as much as Harlan loves NTP :)
Everybody just needs to get their own atomic fountain and we're all good...
No, the drinks from those things go right through me...
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
Here's the point where we differ.
Except that is you just saying a fact is not a fact because you don't want it to be a fact. Microsoft uses the Network Time Protocol and it works across all the major operating systems, this is a fact and no amount of you saying "we differ" is going to change that.
but its provably factually inaccurate based on numerous prior incidents.
No you have it backwards, they use the open source, permissively licensed Network Time Protocol just like everybody else. That's why Windows, GNU/Linux and OSX machines can all synchronize time between them.
which is that Microsoft *certainly* would sabotage NTP
Except the irrefutable fact is that they did not and have not despite always being able to had they wanted to. You clearly need to be educated on permissive open source licensing.
You purport to naively assume this to be the case
I am not assuming anything, Windows syncs time perfectly well from a Linux server and it uses the Network Time Protocol (again permissively licensed) to do so, this is a fact, not an assumption. Does Windows *have* to use NTP? Of course not, but it would be pretty silly if they didn't. So why do you think they wouldn't? And if your thoughts on that are valid then why do they use the NTP instead?
Frankly I've satisfied myself that you're a paid shill, so this conversation is over.
Off you go then, ignore that NTP works just as well with Windows as it does with everything else, ignore that it is permissively licensed, ignore that if they wanted to then Microsoft could have created their own incompatible derivative any time they wanted yet they didn't.
You're obviously upset that despite the *ability* to be as evil as you think they are they didn't capitalize on that opportunity. So the real question is why would *anybody* be so upset about that? It's not at all logical.
"If NTP should get hacked or for some reason stop functioning, hundreds of thousands of systems would feel the consequences."
Hah! Anyone attend DefCon23 last weekend? I am going to assume somebody did because it was awfully crowded at the old Paris Hotel, Las Vegas.
https://defcon.org/html/defcon-23/dc-23-speakers.html#Selvi
The Chrony comparison page compares ntpd, Chrony and OpenNTPd. Another yet to be finished alternative is ntimed (which seems to currently be around 6000 LoC). On some Linux's if you don't care about accuracy or trying to weed out false time you can always use an client such as systemd-timedated.
The very basic idea of the NTP protocol is to disseminate the time using a hierarchical layers of stratums: https://en.wikipedia.org/wiki/...
So by design all nodes that are not a leaf need to be both client and server. This is common to all hierarchical protocols like for example DNS, and proved as an effective solution to reduce the bandwidth of the upper part of the hierarchy.
If you have a better idea, please publish an RFC for an more effective protocol.
It can now keep your clock within 10 milliseconds between syncs. Still not as good as the official NTP.
Depends on your perspective.
To me it is: 10ms with the OpenNTPd vs seconds if not minutes with the official NTPd, which occasionally blankly starts logging some errors or warnings like "oops shit, not syncing anymore".
Official NTPd is capricious as hell. And the documentation is just horrible.
I generally replace it with OpenNTPd which "just works". Because, at the end of the day, I can live probably even with 25ms skew, but the seconds/minutes of official NTPd is just unacceptable.
All hope abandon ye who enter here.