Slashdot Mirror
NTP's Fate Hinges On "Father Time"
Esther Schindler writes In April, one of the open source code movement's first and biggest success stories, the Network Time Protocol, will reach a decision point, writes Charlie Babcock. At 30 years old, will NTP continue as the preeminent time synchronization system for Macs, Windows, and Linux computers and most servers on networks? Or will this protocol go into a decline marked by drastically slowed development, fewer bug fixes, and greater security risks for the computers that use it? The question hinges to a surprising degree on the personal finances of a 59-year-old technologist in Talent, Ore., named Harlan Stenn.
What the hell is there to fix in a protocol solely designed to return a string of numbers?
At 59 years old, statistically Mr. Stenn isn't going to live long enough to maintain NTP for another 30 years. Perhaps something so crucial should be a voluntary communal effort?
Yes but there are an assload of companies out there making a shit-tonne of cash using these FOSS programs and not contributing in any way whatsoever. Its a complete disgrace and they should be exposed for the cheapskates they are.
.
Hopefully the ntp.org software fades away.
However, the Network Time Protocol should live on in more secure and more easily maintained implementations (e.g., NTimed and OpenNTPd).
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.
100 hours a week to maintain NTP? How much of that comes down to answering emails that maybe don't need to be answered? I have a ton of respect for Mr. Stenn, whose name, incidentally, I don't think I'd ever heard until today despite having two systems in pool.ntp.org for years and using NTP in or on nearly every device I've owned for two decades. But there's simply no way there's enough going on in NTP to generate 100 hours of work per week. I see the changelog is active and fresh, but I still can't imagine those releases driving a "crunch time" developer schedule, week in and week out for 3+ years.
I hope he backs away from the email before tossing in his hat entirely. Engaging random strangers in thoughtful discussion is probably consuming a lot more of his time than it needs to, and maybe more than he's noticing.
I have two problems with this article.
(1) $7,000/month * 12 months + additional $12,000/year = $96,000/year, not including any other contributions that come into his non-profit on top of that.
(2) Most of the need for NTP is driven by bad protocol design in client/server software.
NFS, for example, would not need synchronized time if the client would include a "this is my idea of the current time" timestamp in time related requests, e.g. "set mtime".
The server then does:
(clients idea of current time) - (clients desired mtime) + (servers idea of current time) = mtime to set on server
Voila: everything is consistent, clocks don't need synchronized between the client and the server.
Bonus points: network latency adjustment is automatic; no need to go off and implement PTP to get an even more precise version of NTP.
So most of this is a problem we've brought on ourselves by stupidly assuming a client and a server need synchronized time values in the first place, and then designing asinine protocol that build this assumption into the infrastructure built on top of those protocols.
Maybe instead of making NTP more reliable - at a pretty high expense for the small town in Oregon where he lives, and the cost of living is relatively low - we should work to get the rest of our infrastructure away from being addicted to having a synchronized time base in the first place?
PS: Yes, I brought this issue up in the IETF when NFSv4 was being designed in the first place.
Here is an interesting interview with Harlan Stenn at the 2013 Google Summer of Code
https://www.youtube.com/watch?...
Apparently he is keeping 7 doctoral and post-doc students busy working on timestamps, noise and 'something' that he did not seem to have a firm grasp on
He also mentioned a need for admins, a webmail guy and people who want to do documentation
Having been handed projects after a leads retirement, I think that documentation may be the more pressing need
Wherever You Go, There You Are
It's just a computer. It only has to work. How hard can it be?
Wasn't that ridiculous
NTP is also not trivial due to among many other things the large amount of clock drift on a lot of motherboards. If you had an alarm clock that lost an hour in a week you would throw it away, but that's seen as acceptable even for some server boards. So then you fetch the time but it takes time for the signal to get to you, so the time is out of date by the time you get it - which then means trying to work out how long it takes for the time signal to get to you. There's plenty more after that.
I'm just staring at your comment and blinking, because...wow. Even if I ignore #1&2, #3..."and is typically only an issue for calendaring and scheduling." How about queuing? How about clustering? How about expiration of millions of things (tokens, certs, leases, etc). How about practically everything your computer is doing? Unless you're meaning to say that everything really does boil down to "calendaring" and "scheduling," and you're not just making some Outlook comment. If timing wasn't important, there wouldn't be circuits dedicated to keeping it, on practically every electronic device on the planet.
It is absurd to expect a corporation of any size to "toss something your way". He should have told apple, when it mattered to them, that they could pay a service fee to have him delay the patch for their benefit. No, this isn't how you want to deal with individual people. Yes, this is how you must deal with a corporation.
Life lesson: mega corps don't even care for the people they employ, and much less people outside the corporation. A corp is an abstract non-human entity. It doesn't deserve your charity.
I've been on the "NTP Hackers" mailing list for ~15 years now, my last major effort was to develop a server-optimized multi-threaded version of the core ntpd sw: I was hoping for wire speed packet processing on an embedded linux platform, but had to settle for 3-500 Mbit/s since the target kernel version did not support multi-thread targeting of incoming packets, i.e. I needed to have a single receive thread which would fetch the incoming packets, timestamp them and queue them up, then all the other threads/cores would grab them from there.
Back to the "why are there bugs in such a trivial protocol?" question:
By far the biggest cause of required effort when trying to modify or optimize the NTPD distribution is the need to support a big number of OSs and even larger number of OS versions, some of them more than 20 years old, even if the main targets are Unix-like or Windows.
The second problem is the need to support 30+ reference clocks, with all sorts of OS/version specific interfaces needed in order to timestamp events as accurately as possible.
The third and final major stumbling block is all the crypto stuff, which got added in order to be able to authenticate both time packets and monitoring/configuration requests, and this is where the latest major bugs have been found.
PHK (who is working on Ntimed) has spent a lot of time on NTP, including his time as a core FreeBSD hacker when he made sure that the FBSD had the best possible timekeeping kernel. This is the reason that my personal pool server has always used FreeBSD.
If your only need is to get 0.1s level time sync on a number of client only machines, then it really doesn't matter how you implement the NTP protocol, except that you should really try to measure and adjust the local clock frequency so as to track the reference time!
The default Windows time code implements Simple NTP (SNTP) which uses the NTP packet format but doesn't try to implement the proper control loop to steer the local clock, instead it just yanks the OS clock resulting in a sawtooth-like pattern of clock offsets.
Terje
"almost all programming can be viewed as an exercise in caching"
I really don't see the internet collapsing from him walking away. If it was a legitimate issue it'd be quickly picked up by another party, commercial or otherwise. I'd suggest he does just walk away from it. Even if a lot of money was pushed his way, I'm willing to speculate that he's burned out from all those hours (100/wk?) over the years and now wants to just set things up for a new person, step out, and close the door; been there, done that.
If we ceased having any NTP servers, then there's a more likely internet collapse scenario. The current NTP software seems to have been doing pretty good over the last couple of decades; or is there something that's progressively changing?
I appreciate that the guy has put a lot of work in to it, a lot of us (OSS developers) have and it's a passion more than anything else; if you get money out of it, it's a bonus, but one should never engage in it thinking there'll be any rewards other than seeing that the software itself grows and maybe a little bit of acknowledgement of what you've done. The OSS community can't get all up in arms with disgust when large corps use our software to help them progress, while not all corps give back to all projects, there's still a lot of stuff that is given back, or donated, even when not legally required.
The ethics of earning money off the back of OSS could be debated, but that's a whole different sphere. A lot of us already donate a lot of money already to various OSS projects as a nice feel-good gesture as well as a way to encourage further developments.