NTP's Fate Hinges On "Father Time" 287
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.
Fewer bug fixes? (Score:3, Insightful)
What the hell is there to fix in a protocol solely designed to return a string of numbers?
Re:Fewer bug fixes? (Score:5, Interesting)
If it is not broke, fix it until it is.
Is this what keeps projects alive?
Re:Fewer bug fixes? (Score:4, Insightful)
If it is not broke, fix it until it is.
Is this what keeps projects alive?
Yep. New is always better, because shiny.
Re:Fewer bug fixes? (Score:5, Interesting)
NTP doesn't just 'return a string of numbers'.
But either way, the article isn't about NTP the protocol, its about one shitty implementation of NTP that I don't think anyone even uses anymore. Windows and OS X certainly don't.
The summary and headline are equivalent to saying 'Netscape is going out of business, HTTP in danger of disappearing'
If he were to drop dead right this instant ... no one that matters would notice beyond his family.
Re:Fewer bug fixes? (Score:5, Informative)
Feeling grumpy?
From page 2 of the linked article:
Apple Macintosh computers and servers running OSX use NTP, and Stenn said Apple developers have called him for help on several NTP issues. In the last such incident, he said he delayed a patch to give Apple more time to prepare OS X for it. When they were ready, he applied the patch and asked "whether Apple could send a donation to the Network Time Foundation," Stenn recalled. "They said they would do their best to see that Apple throws some money our way." But it hasn't happened yet.
Apparently somebody is under the impression that OSX still uses it, unfortunately this is how the business majors deal withit:
"Everybody loves us," Stenn said. "But people with money say, 'We don't give to open source projects.'"
http://www.informationweek.com... [informationweek.com]
Re:Fewer bug fixes? (Score:5, Insightful)
"Everybody loves us," Stenn said. "But people with money say, 'We don't give to open source projects.'"
They don't give to GPL projects.
They hire BSD developers (CUPS, Clang, etc) because they can keep the parts closed they want.
Re:Fewer bug fixes? (Score:5, Interesting)
So he patched for and worked with Apple and they said we'll see ?
If his time isn't valuable to him why should it be to Apple ? Next time they call he should tell them he can't talk to them unless they fax back a block time purchase agreement with either a check or credit card and a statement they won't charge back.
Re:Fewer bug fixes? (Score:5, Informative)
So he patched for and worked with Apple and they said we'll see ?
The way he did this, it is probably difficult for the responsible person at Apple to actually pay him. He should have offered to do the work as a contractor, someone would have found money in a budget, and when he sends a bill for five days contracting work they pay the bill. That's how it works.
He seems to be asking for a donation to an open source project. How can someone at a commercial company put that in a budget? The financial guys say "is there any legal reason why we have to pay this money", the answer is no, so it won't get paid.
Re: (Score:2)
Sure you could do it that way but why ??
From the reactions you would think Redhat didn't sell support agreements.
Re: (Score:2)
Sure you could do it that way but why ??
To get funding for your FOSS project.
Re: (Score:2)
it would be helpful if it mentioned what the patch actually did.
was a patch for the server, that would have broken osx if rolled out? did the patch then break unpatched osx time sync? or what. I mean, why did he need to delay it? what the fuck? why not make actual sense, maybe people would give you money if you could articulate it meaningfully why you need more money to maintain something that does one thing and has been getting patches for a long time already, never mind that simplification of it to a degr
No business sense (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re:No business sense (Score:4, Funny)
"A corp is an abstract non-human entity"
I know of 9 judges who would tell you otherwise.
Re:Fewer bug fixes? (Score:4, Interesting)
The reference implementation, which is the subject of the article, is what's used by pretty much everyone. Name a significant OS/distribution which doesn't use ntpd.
Oh, and that includes OS X, contrary to your incorrect claim:
--OS X Yosemite
You are correct about one thing - it is a shitty implementation. It doesn't even follow RFC 5905, which it's supposed to be the reference for.
Re: Fewer bug fixes? (Score:3)
Re: Fewer bug fixes? (Score:5, Funny)
systemd will perform the functionality at some point.
Re: Fewer bug fixes? (Score:5, Informative)
Already done for the client part of the NTP: systemd-timesyncd
Re: (Score:2)
Depends on your definition of significant.
OpenBSD
DragonFly
These clearly aren't:
MidnightBSD (my project)
MirBSD
Re: (Score:3)
Re:Fewer bug fixes? (Score:5, Informative)
NTP doesn't just 'return a string of numbers'.
No, sometimes it returns A lot of strings of numbers [sans.edu].
I am one of the ntpd maintainers (Score:5, Interesting)
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
Re: (Score:3)
What the hell is there to fix in a protocol solely designed to return a string of numbers?
Yeah. All You Have To Do Is...
(screams)
Re: (Score:2)
What the hell is there to fix in a protocol solely designed to return a string of numbers?
Because time is a rabbit's nest of problems. https://www.youtube.com/watch?... [youtube.com]
/. is not kickstarter (Score:2, Insightful)
stop hitting us up for money
Re:/. is not kickstarter (Score:5, Insightful)
Re: (Score:2)
Free and Open Source... unless you make money, then fuck you.
What projects need funding? (Score:2)
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 p
Re: (Score:2, Informative)
And nobody is putting a gun to the corporations head to make them give money.
Just because something is legal doesn't mean it's not assholish and deserving of public shame.
Re: (Score:3)
>The software author has the power to control the licence
Except when, like here, it's not the original author. Stenn is maintaining the code and has been for a long time, but NTP was originally written by David Mills.
Mills didn't have the associated costs that Stenn has to deal with - he could do it as a hobby, Stenn can't - that's not viable for NTP today anymore.
Mills is long retired, but HE holds the original copyright and only HE could change the license.
Now of course Stenn could just walk away and g
Re:/. is not kickstarter (Score:5, Insightful)
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.
Re: (Score:2)
1. It is an article about a problem. At no time did he ask for individual donations.
2. NTP is important like SSL is important to the internet in general.
You are not saying anything that helps solve a real problem or contributing to the discourse. So since you commented how would you solve the issue of providing resources for the development of NTP?
Bugs? (Score:3)
Re:Bugs? (Score:5, Informative)
Here is an interesting interview with Harlan Stenn at the 2013 Google Summer of Code
https://www.youtube.com/watch?... [youtube.com]
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
Re: (Score:2)
I think that documentation may be the more pressing need
But the code IS the documentation!!!!
If you want Bugs,... YSou got it ! (Score:2, Insightful)
>> 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.
Not stable yet? (Score:2, Insightful)
Re: (Score:2)
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.
Stable platforms do not survive well in the OSS world. The stack is constantly living, and the components need periodical adjustments to keep them in the wagon.
Re: (Score:2)
Re: (Score:2)
It's gotten more complex because it has security now, which it needs and is broken without it. Crypto, key exchange, etc. So complex enough that it needs maintenance.
Re: (Score:2)
Not only finances are an issue (Score:5, Insightful)
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?
Re: (Score:2, Funny)
according to the article he does the entire project by himself, no wonder its a mess. If this graybeard cant take on a team of young folks then we will have to wait for him to die or a fork.
Re:Not only finances are an issue (Score:4, Funny)
Re: (Score:2)
Apparently he has been working with Google Summer of Code for many years, the linked article does seem pretty alarmist, but that may be what it takes to get people to take action
Re:Not only finances are an issue (Score:5, Interesting)
And at the Google Summer of Code summits I've seen the NTP devs (I can't say if it was him or not) stand up in front of a couple hundred FOSS project leaders begging for help with their bus factor problem.
This sort of infrastructure code is at once niche, genuinely hard work, demanding the highest quality programming skill, unrewarded, non-sexy,
and vitally important to the world.
Re: (Score:2)
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?
From the sounds of it he wouldn't mind a bunch of young Turks with tons of relevant experience saying "Hey, I 'd like to help and am not only willing to do it for free but front some of the costs out of pocket. BTW, I'd love to put in some crazy hours at times where a critical patch needs to come out and get bitched at by people who didn't do anything to help but feel free to complain when they don't like what I did." As others point out, another issue is what happens when he stops doing this? Who takes ove
UI (Score:2, Troll)
Protocol vs software that implements it (Score:5, Insightful)
.
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).
Re: (Score:2)
Re: (Score:2)
...
You should look at OpenNTPd. Much, much easier to configure.
.
The config file on one of my servers has one line in it, the name of the server pool to sync to. With that one line config file, OpenNTPd syncs to the servers in the pool and does not open any ports for listening.
Summary of above post (Score:4, Informative)
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.
Re: (Score:2)
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
Not a particularly hard problem. Take the round trip time, and divide by two. That should get you within a few ms. If you have special needs for better performance, get a cheap GPS unit and attach it to a local server.
Re: (Score:3)
Now add security, because if someone is spoofing the time they can really mess things up badly in a lot of ways.
Re: (Score:2)
> get a cheap GPS unit and attach it to a local server.
Yes, I should buy 40,000 cheap GPS units. Actually, you know what? I'm going to ask Dell, HP and Intel to implement this. Oh crap, I can't, 'cause I can't get a GPS signal in a DC.
You really didn't think about this too hard did you? People have been working at this for years, NTP does a heck of a lot of stuff to ensure that the clock is accurate, and how much you can trust the information you're given. NTP isn't a cheap hack, it's mathematically bril
Re: (Score:2)
Re: (Score:2, Insightful)
Even if OpenNTPd wasn't broken it's a very poor substitute for NTPD...
You say OpenNTPd has been broken "for years", yet do not say why or how. -1 for your efforts.
.
For my needs, OpenNTPd has been an excellent replacement for NTPD. I do agree that NTPD has some features that are not present in OpenNTPd, but my usage does not require those more esoteric features. What I do need is the ability to sync my server clocks within a few milliseconds, OpenNTPd does that quite well. And OpenNTPd does have one major feature that NTPD has lacked of late - security.
... I had not heard of NTimed until just now.
You should try t
Re:Protocol vs software that implements it (Score:5, Funny)
You should try to keep up. :)
He doesn't have time.
Re: (Score:2, Informative)
The timekeeping of openntpd is normally quite good, but there can be really large outliers (up to several 100 ms) which is totally unacceptable for most use cases. Not so much that the time is wrong by 100 ms (almost noone cares) but the fact that it slews the clock way fast/slow to get there messes up many things.
It also cannot correctly deliver time to other systems, as it claims to be way more accurate than it is.
100 hours a week? (Score:4, Interesting)
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 [udel.edu] 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.
Re:100 hours a week? (Score:5, Insightful)
For someone who's so deeply invested in managing the Network Time Protocol, this dude really doesn't seem to be able to manage his time very well.
Windows uses NTP now? (Score:2)
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.
Re: (Score:3)
yeah, on my personal laptop (not part of a domain) the Date and Time window has a tab named "Internet Time" that my work laptop doesn't. That's NTP (or was last time I actually dug into it), though their list of servers is kinda small.
Re: (Score:2)
Windows has done NTP since Windows XP. Before that you had to either ask the domain controller or use a third-party NTP utility.
Re: (Score:2)
Re: (Score:2)
Yes, ActiveDirectory time is synced via the NTP protocol.
ActiveDirectory is a collection of protocols, most of which are based on public standards, NTP, LDAP, Kerberos, ect. Plenty of Microsoft Proprietary piled on top too.
You can point any NTP client at an active directory server and sync from it, just like you can use it for a kerberos realm out of the box, and with Services for Unix installed on your AD server, the schema is extended to support the various Unix attributes required to use nss_ldap and pu
I have two problems with this article. (Score:5, Funny)
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.
Re: (Score:3)
Didn't the NFSv4 design decision to use Kerberos for authentication mean that some kind of time sync would be needed anyway whether NFS itself mandated it or not, since Kerberos relies on synchronized clocks?
Re: (Score:3)
Correct. Kerberos requires a reasonable synchronization of system clocks in order to work. Thus NFSv4 indirectly requires some form of time synchronization.
Re:I have two problems with this article. (Score:4)
Correct. Kerberos requires a reasonable synchronization of system clocks in order to work. Thus NFSv4 indirectly requires some form of time synchronization.
Only if you do not also update the Kerberos protocol.
Re: (Score:2)
Um, don't forget timezone, daylight savings, leap seconds etc...
I think that the 'synchronized time base' thing becomes an issue with transaction processing, surely there are other issues as well what with it having been accepted as part of the environment for the past three decades
Re: (Score:3)
time synchro service doesn't need to care about timezones, daylight savings or such.
the client operating system needs to know it's relation to utc.
Re: (Score:3)
It would be a giant step forward if NTP will be able to broadcast TAI, the leap second table, and the timezone database.
The leap second table and the timezone database are dynamic informations that need to be updated at least 2 times per years. You can arg that this can be done using the operating system upgrade, but the reality is that many machines will not be updated for whatever bad reasons. So carrying the informations using NTP (or PTP or GPS for that matter) will be an clear advantage.
Re: (Score:2)
we should work to get the rest of our infrastructure away from being addicted to having a synchronized time base in the first place?
There are thousands of other uses for accurate clocks on computers besides NFSv4.
There are 3 types of time that matter to computers (Score:2)
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
Re:There are 3 types of time that matter to comput (Score:4, Insightful)
Re: (Score:2)
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 wh
Re: (Score:2)
I partially agree with the sentiment of point 1, but he does have fixed costs to consider. That 96K isn't just salary. Still, I'm not sure it constitutes being impoverished the way the article paints it
On point 2 however, I think you are way off base. That statement really glosses over what it means to have synchronized time and why it is necessary. Two computers agreeing on the time between each other is not sufficient to be considered synchronized from a security perspective. To be synchronized for s
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
What kind of hole can be opened in a server due to a bad clock? Serious question.
Non-expiry of certificates, tickets and other time-based credentials, for one thing.
Re: (Score:2)
Stuff dependant upon time of day, ACL restrictions, replay attacks of time based credentials (Tokens I guess in the previous post).
Even log analysis across systems if the clocks in different systems are drifting faster and slower according the the temp of the system would be a major PITA.
Let's not start looking at the consequences to financial exchanges (Expiring bond markets, matching trades across disparate systems), telephony (TDMA, billing systems), depending on how far you take it, train signalling, ai
Re: (Score:2)
Sounds like the issue is that certs have expiration dates -- which is dumb.
"I trust you today, in 2017 I won't though."
That is just asinine. Either the two sides trust each other or not, the "current date" of the clock on either side should not invalidate that trust.
Great! NOW How is VeriSign supposed to make money, if they can't charge you over and over again every year for the same thing, where only the expiration date and signature block are different? 1/2 8-)
Re: (Score:2)
The purpose of NTP is to accurately set the clock. There can be many reasons for this, not just network protocols that may depend on it. It may be that some people just like having the computer clock set with close to atomic clock accuracy. It is true that network protocols should be more resiliant to unsynchoronized clocks at either end, but this does NOT negate the need for NTP, since many use it to keep the computer clock accurate to have an accurate clock and not have to constantly readjust it, for thei
Re:I have two problems with this article. (Score:5, Insightful)
Why build time-fragile systems? (Score:2)
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 th
Re: (Score:2)
" by stupidly assuming a client and a server need synchronized time values in the first place"
Have you worked with Amazon S3?
If your time is off by more than 15 minutes than Amazon's servers, you get a big ol fat rejection response saying your clocks arent sync.
Re: (Score:3)
It is impossible to "synchronize" time between gravity wells because time ticks at different rates.
No, it doesn't.
It is observed differently.
Keeping the observations in sync is easy, you base your ticks so they synchronize with ticks of a stationary object in free space. So if you happen to be near a black hole, your clock has to 'tick' much much faster to stay 'in sync' with the pacemaker. Its trivial to synchronize clocks since time is an arbitrary measurement.
Re: (Score:2)
Would 'make' across multiple mounts work to build Linux with non-synched time?
Well, probably not Linux, at least if you were using the Debian Build system, but that's because it probably wouldn't work on a standalone machine, either... OK just joking! Put down the knives!
The answer is "Yes, it would work", because you'd use the same technique to take a server response in server time and delta it to local time for the "stat" issued over NFS by the "make" process, so the local node always has a consistent view of the relative timestamps on the server, even if the local node's clock has
Re: (Score:3)
"network latency adjustment is automatic" - I don't understand this statement.
If you are only taking two time stamps - client transmit and server receive - then you have no information about the network latency.
You don't NEED information about the latency, as long as the latency in both directions is equal. It's going to be included in the delta + now on the mtime set, and it's going to be subtracted back out on the -delta + mtime stat on the way back.
As long as it round-trips like this, the latency is actually immaterial. Which is the point, since your latency between your NTP source and your file server vs. your latency between your NTP source and your file server client can be unequal, which will screw your t
ESR's doing something related to NTP right now... (Score:2)
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.
Re: (Score:2)
ESR maintains gpsd, which ntpd can use as a clock source.
His most recent time-related post is here [ibiblio.org], Introduction to Time Service. Before that, it was a gpsd release [ibiblio.org].
time_t (Score:2)
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?
Re: (Score:2)
time_t has been 64 bits on every *nix system I've used for over a decade.
all widely used 32-bit linux ports still have 32-bit time_t (x32 has 64-bit time_t but that is not widely used and it's debatable whether it counts as a 32-bit system). While x86-64 is taking over on the desktop and dedicated servers many embedded systems and low cost hosted vms are still 32-bit (the latter due to the lower memory footprint).
Why in the name of any sanity at all would NTP not have been updated by now?
Afaict it has, the NTP "DATE" format provides a 32-bit era number and a 32-bit era offset number which between them provide a 64-bit seconds count. The NTP "timestamp"
NTP, GPS, PTP: same problems (Score:2)
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 eve
Re: (Score:3)
Re: (Score:2)
You could just check yourself
http://tools.ietf.org/html/rfc... [ietf.org]
http://tools.ietf.org/html/rfc... [ietf.org]
Re: father time (Score:2)
Re: (Score:2)
SwissArmyd (Score:2)
I use systemd as my window manager and email client. It's Eudora emulation mode has much improved in the last release.