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?
stop hitting us up for money
Given 30 years, a single protocol, and 'many eyes'...what is there to fix or update?
will and will always have been Dave Mills
shame on you
No offence, but NTP simple time protocol as it is is surely reliable enough that it doesn't need more maintenance (after IPv6). Don't fix what ain't broken.
Slashdot, fix the reply notifications... You won't get away with it...
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?
work less at this hobby. Mails will pile up, and someone will take the hint.
"Complete freedom" is a great theory but people need to eat and when a company has to release all source code with a binary they're probably less likely to put time into that source code.
iXSystems picked up FreeNAS development and contributes to it as well as FreeBSD, but they don't have to release their secret bits on their sold products. Apple and Juniper are also contribute code because they can keep the parts they want to secret.
CUPS is the backend to OS X's printing and as soon as Apple picked it and hired the developer the UI actually started to become usable. I'm sure half of their code isn't released but Linux still gets to benefit from the parts that are. We also aren't reading about how Michael Sweet is 'scraping by' and the dire state of Linux printing.
Someone is dying to put a new UI on it.
You don't need to keep developing it, because it works. Next?
.
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).
if the thing is still using the old 32 bit time routines based on seconds from 1970. that would fail at around 2032.
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.
Serious question. Last time I worked with with a Windows network, time was set by the domain controller on login.
I think, anyway. That was a long time ago.
Those who can't do, teach. Those who can't teach either, do tech support.
OpenNTP.org
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.
At least accordingly to a comment of his on his latest blog entry.
So I expect that the fate of NTP isn't so uncertain as all that, though whether Stenn himself will still be the lead is an open question.
SystemD will just swallow it and replace it, if not already done.
ESR maintains gpsd, which ntpd can use as a clock source.
His most recent time-related post is here, Introduction to Time Service. Before that, it was a gpsd release.
See that "Preview" button?
time_t has been 64 bits on every *nix system I've used for over a decade.
Why in the name of any sanity at all would NTP not have been updated by now?
I do not fail; I succeed at finding out what does not work.
The Linux group has a list of critical software. Either team GNU or the FSF (or the Linux Foundation) needs to audit critical pieces of vital but "non-shiny" pieces of software like NTP or BASH or DNS or SSL and backstop them both financially and with human resources. Companies who use the software should be asked to pony up with either cash or programming bodies (or both). Everyone agrees that its critical (or at least important) infrastructure, so coughing up cash to pay for the service is reasonable. Certainly if these things start to fail (Hello Bash, Hello SSL) everyone throws blame at free software and "how could they let this happen?!?!?", yet supporting those who provide the service is lacking. This must change. At the very least, kickstarter campaigns providing a few years worth of funding per developer would be a start.
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.
There are 3 types of time that matter to computers:
(1) "Now" - which doesn't need time sync
(2) "Relative to now" - which also does not need time sync
(3) "Absolute time" -this one needs time sync, and is typically only an issue for calendaring and scheduling.
If you're an astronomer, absolute time maters - or actually, "Local Apparent Sidereal Time", which also ties it to a specific longitude and latitude, so that you know where to point your telescope.
Most applications of time on computers fall into category #1 or #2; this includes *ALL* filesystem operations, and most other operations not related. Even calendaring is not an issue, if you use a mobile device (which can sync to the server providing network service, so long as it's not direct satellite), OR if you use a web client (in which case all dates are server dates anyway, and there's no such thing as client dates).
Face it, it's a design problem for about 95% of all applications in use today.
Systemd will take care of all that. Everything needed for everything will be provided by and run by Systemd.
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.
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's not an issue for queueing; you enqueue things "now". So, for example, you could modify IBM's MQSeries, if you cared about time-ordering events, and either include the idea of "now" relative to the enqueue time, with another received timestamp on the system where the data was enqueued. This would work for ordering stock transactions, for example, because if your order gets there later than Bob's order, it doesn't matter: you lose.
I'm uncertain how to respond on clustering; it would really depend on what you are talking about clustering, and your cluster architecture, but I see no reason that knowing what time it is is somehow more valuable than, say, load average on a given node. If you care, you include it in the cluster-sync information (no need for NTP, since you're already dealing with syncing a *lot* more information than just the time, and so time gets a "free ride" on the clustering protocol.
Expirations are all relative to the time of issue. Unless you are talking about something like X.509 certs, in which case, the issue is only relevant to the person signing the cert getting payed at intervals, and you'd otherwise just look at the CRL for the CERT, and if you couldn't contact the site that owned the CRL, you have to assume revocation anyway. But yeah, I'd call that a calendaring problem. Leases can be handled by op locks; that's how NFSv3 + leases handled them, and it's how SMB handles them today; the only thing you care about there is breaking the lease, and that's a relative time and/or "Now" event.
Tokens are handleable at the protocol level. The token issuer issues a relative timestamp, and you can compute a relative local stamp to decide when to ask for a renewal (just like DHCP leases are handled), or, you can eat the error handling when you try to use an invalid token, and as part of the error handler, ask to renew then.
"Practically everything my computer is doing" can be done in local relative time; unless I want a remote resource, all my local resources can be handled in relative time, and if I decide I actually give a damn, then I can worry about something like NTP, if I'm too cheap to buy a GPS receiver and/or something that can receive the time base broadcasts from my local cell tower (assuming I don't already have a cellular or WiFi in the computer, because otherwise, I just consult those).
And I think you are confusing "this is the current wall clock" with "I need to handle the switch debounce within 60ns" or "I need to do a context switch when the LBOLT fires", which are not things NTP would be/should be involved with.
PS: An engineer on LinkedIn was getting all angsty about an IOT device that he was worried about setting the timezone on. I convinced him to just put his log timestamps in UCT, and he was still angsting about what to put up for the time on the LCD, and I suggested he either put "UCT" after the time display, or ... just don't display the time. There's actually no great reason to have *another damn human readable clock* on his LCD just to have something to display, since we are completely outnumbered by human readable clocks practically everywhere in our daily living environment, and if a human wants to know the time, they can look at one of those.
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.
hell, they don't even give us shiny gold any more :0
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"
The article claims that
On a daily basis, NTP also consults atomic clocks, which tick off precise seconds based on radioactive Cesium-133 decomposition
. Luckily, or timekeeping doesn't rely on the purely random radioactive decomposition. It's the transition between hyperfine ground states of caesium-133 that were defined as the base for the second.
I'm uncertain how to respond on clustering; it would really depend on what you are talking about clustering, and your cluster architecture, but I see no reason that knowing what time it is is somehow more valuable than, say, load average on a given node. If you care, you include it in the cluster-sync information (no need for NTP, since you're already dealing with syncing a *lot* more information than just the time, and so time gets a "free ride" on the clustering protocol.
Frankly you haven't a clue what you're talking about.
At least accordingly to a comment of his on his latest blog entry.
So I expect that the fate of NTP isn't so uncertain as all that
You mean that NTP is certainly dead?
Watch this Heartland Institute video
I don't know what the time is on YOUR wrist-watch, yet I can still communicate with you.
If your cluster software requires sync'd clocks to work, then it is already riddled with race-conditions or other bugs. Will you software work if the clocks are 1min off? How about 1s off? 1ms, 1ns, etc, etc? Even atomic clocks are not perfectly sync'd.
I use systemd as my window manager and email client. It's Eudora emulation mode has much improved in the last release.
My Other Computer Is A Data General Nova III.
>> That's the problem: not enough bugs. Time to replace it with the Apple Watch Protocol.
No. If you want the most buggy and incomplete reference implementation, then take the microsoft one.
aaaaaaa
Esther, please go back to school and take the higher numbered classes. They will hopefully teach when an idea is about something important and when it's embarrassing fluff.
"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"
Really?
As much as we can shit on corporations for not paying the piper, I am sure many are oblivious who they need to be supporting and funding. How many of us on /. actually are aware of the time and effort spend by certain individuals to ensure backbone implementations are kept in a healthy state. I am sure many corporations on in the same spot, after all they paid RedHat or some other vendor for a solution and that's probably as far as it went. Many of us take these projects for granted.
The other issue is the people who need funding are usually unknown until they are in dire straits. I am not sure the best way to address this issue? How does funding *BSD help? Does the FSF provide any method for easily providing funding, for them to distribute to these core solutions?
Jumpstart the tartan drive.
you, know - you're right. Instead of having a simple, lightweight protocol that keeps time accurate across the globe, to the tiniest portion of a second...we should have every single time-sensitive thing on every single machine everywhere re-write their own time service. That way, not only will everything suddenly become substantially more noisy, but risk factors will go through the roof and code complexity across all of the IT universe will dramatically increase! Or, we could just use the tiny, lightweight, extremely accurate tool that's been doing it very well for decades. Damn, such hard decisions...
How are you writing your own time service? You are sending deltas around.
Nothing stops you from syncing your clocks if you want, but the main gist if the article was "OMG! NTP might have a vulnerability discovered! Better fund it more than the 100K a year the guy already gets, just in case!".
If your protocols aren't time-sync fragile as shit, then it doesn't matter if you turn NTP off when/if a vulnerability is found, wait for a fix without your entire business going down because NTP is turned off, and then turn the damn thing back on after installing the fix.
Why build time-fragile systems?
In order for you to make that determination, *you* must know what he is talking about. Unfortunately, nobody else reading this thread knows what either of you are talking about! Your problem is the failure to maintain coherency between two dependant systems. Your rush to ad hominism, while acceptable shorthand, breaks the logical continuity of the argument and leaves the casual reader trapped in limbo without a reference frame. /etc/systemd/system so at least the rest of us can run a backtrace on your maniacal rants.
Systemd probably could have prevented this by restarting your argument without relying on ntpd itself, which is what I think the parent was trying to suggest. So, next time you want to start a pissing contest, please put your script in
http://support.ntp.org/bin/view/Main/SecurityNotice
While each of those protocols have some advantages depending on the network availability, there all need to be upgraded to bring all the features required to make almost every applications happy.
* NTP need to broadcast TAI time, leap second table and timezone database.
* PTP need to broadcast lead second table, and timezone database.
* GPS need to broadcast at least the leap second table (serialized into a few bits over a long period), timezone database will probably be too big.
The TAI time is required to every strict realtime applications that don't rely on the Earth rotation. This is the only time where you can safely add and subtract time and get a precise result in any cases.
The Leap second table is required to every applications that depend on the Earth rotation, like for example the UTC time. Without the leap second table you can't precisely compute past time across leap second inclusion. But remember that even with the leap second table you can NEVER precisely compute future time across possible future leap second inclusion because the Earth rotation is unstable and the decision to include a new leap second is done on a 6 months basis.
The timezone database (and the leap second table) is required to every applications that need to manage local time depending on the location on the Earth surface. Without up to date timezone database, you can't precisely compute the local time of a past event. Because future time rely on future leap second inclusion, you can NEVER precisely compute future local time across possible leap second inclusion.
The nirvana would be that most concerned standardization organizations (ITU, ISO, IEEE, POSIX, etc...) and scientists agree to write a reference library to solve all the time computation, exchange, and broadcasting problem. Almost every libraries and languages are incomplete or compute imprecise result without warning.
As for the leap second abandon, it's a false problem: the reality is that the Earth rotation is unstable and that life activity on Earth deeply depend on the Sun light. A post-correction system will always be required. Mixing it with the timezone offset is a very bad option that will even more confuse the already hard problem of the timezone across the whole Earth surface. But it would be an advantage to make the leap second table available from the timezone database.
Comment removed based on user account deletion
Not to protect douchebag apple guys, but even if developers who contacted the "NTP dad" wanted Apple to throw a donation, then it would be real hard to push by the accounting. If they, on the other hand would be billed for "3rd party expert services" - noone would blink an eye, so, yes, if a large corporation contacts you asking to help fix something - send them a bill first.
I very much doubt the people who contacted hime are actually douchebags.
They're probably just Apple developers who are not authorized to spend company money on their own. Not on donations to open source projects, and not to pay for contract work for that matter. They were told by their boss to fix NTP, they looked into it, sent an email to the guy on the project page, and the guy responded. Work got done.
Seen it a million (well, a dozen) times. The people holding the purse strings aren't the people who do the work.
Is this the protocol that DDOS attacks use for bandwidth amplification ?
As in "send a short question requiring a long answer but spoof the originating IP address"
Or am I thinking of a different NTP ?
The real types that matter to computers are:
(1) TAI: Don't depend on the Earth rotation or on the position on the Earth surface. The only time safe to compute any past and future time as log as you have enough bits to store the number.
(2) UTC: Depend on Earth rotation but don't depend on the position on the Earth surface. Require the leap second table to safely compute some past time. Unsafe to compute future time because of the Earth rotation instability that make future leap second unpredictable.
(3) Local time: Depend on the Earth rotation and on the position on the Earth surface (and local government decision). Require leap second table and timezone database to compute some past local time locally on the Earth surface. Unsafe to compute future time because of the Earth rotation instability and future timezone changes impossible to forecast.
Astronomers more likely uses one of UT, UT0, UT1, UT1R, UT1D, or UT2: something that is more bond to the real physical angular rotation of the Earth.
Information Week is confused about the difference between open standards (TLS, Domain Name System, Network Time Protocol) and open source (OpenSSL, BIND, NTPD). But they're a rag anyway. For that matter, they seem to be confused about the difference between definition and geography - Greenwich Mean Time is a known source of reliable time, as is the US Naval Observatory.
Yes, there's an issue here about a critical component of technology - but the Information Week explanation just contributes to ignorance and stupidity in general.
There's no way to say this politely so fuck it here goes:
Your post is ignorant beyond belief. This could only come from someone who doesn't know jack shit and worse, doesn't know that they don't know jack shit. And even worse than that, you're arguing with people who do have a clue. You clearly don't have any experience architecting major distributed systems. Or major systems of any kind. If you've worked on distributed systems at all, they were almost certainly synchronized and you just never realized how important that was.
Every major distributed system synchronizes their clocks, and when clocks go out of synch bad things happen. The exact amount of tolerance varies, but generally sub-second accuracy is a minimum. Once the clocks go out of synch, every thing from minor random glitches to major meltdown starts happening. And it can be very hard to diagnose what is even happening because you can't easily determine the order that things happened.
And that only scratches the surface of what's wrong with your post. You just clearly don't understand the problem.
I'm sure the OP realizes that "when clocks go out of synch bad things happen.". The point he is trying to make is that this is a poor design. Those software packages should be fixed, so out-of-sync clocks do not affect the proper functioning of the software.
Once the clocks go out of synch, every thing from minor random glitches to major meltdown starts happening.
That sounds like race-condition bugs in the code, which are being band-aid'd over with hacks based on timestamps -- you know it, and I know it.
Greenwich Mean Time is a known source of reliable time, as is the US Naval Observatory. Their time is based on the solar day -- the time it takes for the earth to complete a rotation in its orbit. NTP consults UTC or Universal Coordinated Time, which is Greenwich Mean Time expressed in the military's 24:00:00 hours terms.
On a daily basis, NTP also consults atomic clocks, which tick off precise seconds based on radioactive Cesium-133 decomposition. A GPS receiver can be tied into an NTP server, and use the transmission of a GPS satellite to get the correct atomic time. A GPS satellite has three atomic clocks, so if one falls out of synch, the other two can overrule it and keep the system on track. For GPS time to be off by a billionth of a second means its answer to a location query will be off by a foot. So GPS relies on precisely counted time, not the solar day.
Wow, that's so bad I'm not sure where to start; "Greenwich Mean Time" is a) a timezone still used by the UK when "British Summer Time" is not in effect, and is similar but not the same as UTC "Universal Coordinated Time" timezone, c) based upon the mean solar time at the Royal Observatory in Greenwich, London, UK.
UTC "Universal Coordinated Time" is the present day global standard time reference (yes damnit that is the correct English name, in French "temps universel coordonné" or unofficially "Universel Temps Coordonné" with an unofficial English name of "Universal Time, Coordinated" to keep the abbreviation similar to UT0, UT1, etc.).
The "military time" (i.e. 24-hour clock) reference is nonsense, and ignore 24-hour clock usage in civilian European life, and as well as being standard in anything time oriented.
NTP is references to UTC, but UTC is in fact itself coordinated globally by about 80 national labs that operate their own national time references (typically 3 or more Cesium based time references, larger labs include hydrogen masers) which is coordinated by BIPM (International Bureau of Weights and Measures located in France). They work with International Astronomical Union (IAU) for things like determining when leap seconds are necessary to keep errors minimal. The largest contributors (by clock sources) are the US National Institute of Standards and Technology (NIST), US Naval Observatory, and the UK National Physics Laboratory (NPL) as I recall. The UK NPL and US NIST being pioneers in Cesium (Caesium) clocks.
GPS has become the dominate, and preferable means of professional time synchronizations over distance due to the presence of rubidium or caesium references on board the GPS satellites themselves, and the proliferation of low-cost, widely-available GPS receiver modules including time-synchronisation models with 10s of nanosecond or better accuracy (uncertainty). This means GPS has also become the preferred means of high quality synchronization of NTP "masters" or low stratum references. -- The under-noted point that GPS's geo-location functionality requires a high precision time synchronization between the multiple satellites to determine a position with any amount of accuracy (bounded uncertainty).
Astronomers use sidereal time.
You are right. Maybe the list should be GMST, GAST, LMST, LST ? Taken from "Astronomical Times" page here: http://www.cv.nrao.edu/~rfishe...
...How about queuing?
Queuing should not depend on time, AT ALL. A queue (like FIFO) only cares what is FIRST and FIRST is defined by NOW on the local machine -- what the remote clients think the current time is, is irrelevant. Even if one remote client sent something first, and network delays caused his request to come in second is irrelevant -- it only matters what order requests are RECEIVED on the node that controls the queue.
How about clustering?
What about clustering? Who's clustering technology requires time-sync'd clocks, and why?
How about expiration of millions of things (tokens, certs, leases, etc).
Expire-time would be #2 ("Relative to now") -- Example: Now + 1_day, which would expire a lease 24 hours from now.
In no way do these functions require time-synchronization with some remote machine.
BTW: certificate expiration is stupid -- but yes, if you want to let a timestamp in something you didn't generate affect your behavior, then you need your clock to be roughly in sync with that other party that generated the timestamp. It is indicative of a bad design: you trusting timestamps in something you did not generate, hence is forcing you to sync your clock with them to function properly.
If you generate the token/cert/lease yourself, then it is #2 ("Relative to now") -- you do not need to sync your clock with a third-party.
How about practically everything your computer is doing?
There is not a single thing my computer is doing that requires it to be clocked sync'd with anything else. You have failed to name a single one (I want the name of the software package). I can set my system's date to Nov 12, 2007, and it will still function perfectly, and even interoperate with the majority of services on the internet.
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.
I didn't get that impression from him -- he is saying that 95% of software does not rely on time synchronization. Of the 5% left, 95% of them, do not NEED to rely on time synchronization (they have bad designs).
If timing wasn't important, there wouldn't be circuits dedicated to keeping it, on practically every electronic device on the planet.
No one is doubting that we (as humans) are wasting tremendous amounts of energy on a problem of our own making.
No, asshat. A corporation, like soylent green, is a collection of people.
The real "Father Time" is Dr. David L Mills at the University of Delaware.
Dr. Mills' NTP pages are at http://www.eecis.udel.edu/~mills/ntp/html/
(There are other inaccuracies in that article, BTW)
Way to prove a point when you don't even know what a race condition is.
Oh really? I think I nailed it:
https://en.wikipedia.org/wiki/Race_condition#Networking
IT's not an issue for queueing; you enqueue things "now".
So you just rebooted your computer. Now when the fuck is now? How can I "calendar" something if I don't have a fucking clue what "now" is?
I'm sure the OP realizes that "when clocks go out of synch bad things happen.". The point he is trying to make is that this is a poor design. Those software packages should be fixed, so out-of-sync clocks do not affect the proper functioning of the software.
Once the clocks go out of synch, every thing from minor random glitches to major meltdown starts happening.
That sounds like race-condition bugs in the code, which are being band-aid'd over with hacks based on timestamps -- you know it, and I know it.
I've never heard of NTP synchronization being used as a fix for a distributed race condition bug, but nothing would surprise me. Time synchronization can eliminate some kinds of distributed race conditions, but that's not a band-aid any more than atomic operations are a band-aid for non-distributed race conditions.
Time synchronization is a surprisingly difficult thing to do, so methods of dealing with unsynchronized clocks have been around for a long time, such as vector clocks and Lamport timestamps. But that introduces complexity that can be avoided with synchronized clocks.
But as difficult as it is, we have reasonably good time synchronization protocols, like NTP. Some distributed algorithms can be made much simpler with synchronized clocks. Distributed caches and distributed transactions come to mind, but there are many others. Once you have it for one thing, it tends to get used more and more.
Not to mention that clock time is also just an essential part of the problem domain for many distributed systems (e.g. stock trading, banking, remote sensors, intrusion detection, security auditing, anything real time.) So since you have to have it anyway, you might as well use it.
So, no. I don't think it is necessarily better to "fix" things so they don't depend on time synchronization. That is a step backwards actually. What really would really be better is better clocks (it's amazing how bad PC clocks are) and better time synchronization protocols.
The "bus" test is simple - if XYZ developer fell under a bus, could the project continue operating without disruption?
The fact that Stenn feels he can't take vacations is a good sign that NTP would fail this test.
When a fix for CVE-2014-9295 was already available to build and install on the day, I sent support.ntp.org $100 without hesitation. And was vaguely hoping the rest of civilization -- the part for whom the whole of that sentence was meaningful, anyway -- might do the same. I'm glad a little light is being thrown on some of the infrastructure we take for granted ... worth consideration if you support the FOSS model philosophically, and have a few $ to spare to back it up.
TD