Google's New Public NTP Servers Provide Smeared Time (googleblog.com) 179
Google says it has built support for the leap second into the time servers that regulate all Google services. An anonymous reader shares a blogpost by Google:No commonly used operating system is able to handle a minute with 61 seconds, and trying to special-case the leap second has caused many problems in the past. Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and "smear" the extra second across these twenty hours. For timekeeping purposes, December 31 will seem like any other day. All Google services, including all APIs, will be synchronized on smeared time, as described above. You'll also get smeared time for virtual machines on Compute Engine if you follow our recommended settings. You can use non-Google NTP servers if you don't want your instances to use the leap smear, but don't mix smearing and non-smearing time servers.
Does this mean.... (Score:4, Funny)
Does this mean that my DPS will be slightly higher on December 31st?
Re:Does this mean.... (Score:4, Funny)
That depends largly on whether you play better or worse while drunk. The NTP server tweak will be a secondary effect at best.
Re:Does this mean.... (Score:5, Funny)
Does this mean that my DPS will be slightly higher on December 31st?
No. It means you'll lose a second of uptime.
Re: (Score:1)
It's one of those places where you have to see how it works into your MinMax spreadsheet. If you're a tank, uptime gives a bonus to drawing aggro, so you'll want to use the non-smearing servers to get that extra second of uptime. On the other hand, glass cannons will want to use the smearing server to get the DPS bonus.
Re: (Score:2)
That depends on how many dicks per second you normally take. I doubt a single extra second makes much of a difference except if you're real fast.
Not new, just a holiday reminder PSA (Score:5, Informative)
Google has been smearing leap seconds over NTP since 2011 [blogspot.com]. This is a public reminder that Google NTP will be serving smear seconds because there is one coming.
Smeared Seconds (Score:3)
Re: (Score:2)
Re: (Score:3)
Leap seconds: even less desirable than Daylight Saving Time.
Seriously, why do we put up with this shit. The precise details of the Earth's rotation just aren't that important, except to a few hundred professional telescope operators, who have a history of keeping time their own way anyhow.
Re: (Score:2)
The precise details of the Earth's rotation just aren't that important, except to a few hundred professional telescope operators
My guess is that there are way more navigators than astronomers who need accurate time. Navigation is essential for safety. Sure, celestial navigation is only a backup for GPS these days but I think we'd all prefer that there was a backup available. The US Navy certainly thinks so. At the equator, four seconds makes a difference of one nautical mile.
The US has been pushing for the abandonment of leap seconds for some years but has so far failed to have the standard changed.
Re: (Score:2)
Any failure to add leap days and leap seconds will result in long term violation of these two "truths" and the calendar system becomes meaningless.
Leap days are important. We managed without leap seconds until quite recently, and we could keep on managing. There are already plenty of places where the sun isn't "reasonably close" to the zenith at noon, and we survive. Aside from DST, timezone gerrymandering has produced some timezones that stretch across quite a bit of longitude. Heck, even within a normal-sized timezone, you can be off by 30 minutes if you're near the edge. Compare that error to the 27 leap seconds added over the past 45 years.
"
Re: (Score:2)
No.
"or, heck, by then who knows how many planets Mankind will have spread across, "
You're a space nutter. If you think we're going anywhere within the next few thousand years you are grossly mistaken. The physics doesn't allow it.
As for your arguments against leap seconds. I hear you, and I understand your argument. The point is: the correction can be applied on an arbitrary timescale. Do we apply nanoseconds every few weeks? Or minutes every 30-100 years? Or something in between? Unless there is some other
Re: (Score:2)
If you think we're going anywhere within the next few thousand years you are grossly mistaken. The physics doesn't allow it.
Mars and Venus are both easy, by the "centuries from now" standard. Neither will have a 24-hour day.
Do we apply nanoseconds every few weeks? Or minutes every 30-100 years? Or something in between?
I stand by "never" as the preferable choice. The timing solution is not "required", heck, it's barely even "useful".
Re: (Score:2)
It's Google doing this. You just have do it Google's way because someone at Google arbitrarily decided it was the best thing to do for Google, regardless of existing standards, other environments or systems, or indeed the rest of the world breaking as a result.
Look at Gmail's implementation of addressing. Dots in the user portion of the address were significant in 1982 (RFC 822 / STD 11), but not for Google, who cannot differentiate Bob.Dole@ from BobDole@. Still. In twenty-freaking-sixteen.
Sounds like a part of the Star Trek:DTI Manual (Score:5, Funny)
"don't mix smearing and non-smearing time servers"
Re: (Score:2)
"don't mix smearing and non-smearing time servers"
And here I thought it sounded more like crossing the streams. Spengler told me to never cross the streams.
Re: (Score:2)
Don't mix the time servers or cross the beams. It would be bad. Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.Total protonic reversal! Important safety tip. Thanks, Google!
Comment removed (Score:5, Funny)
Re:Some examples of smeared time (Score:5, Funny)
And meanwhile 4:20 enjoys a joint off to the side.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Nice one: just logged-in to say that was brilliant!
The 7th voyage (Score:3)
by Stanislaw Lem comes to my mind reading this.
"Well, the Monday me on Monday night became, Tuesday morning, the Tuesday me, and so on."
http://webcache.googleusercont... [googleusercontent.com]
Don't mix the servers? (Score:1)
Jesus Christ, this sounds like an April Fool's joke.
Falsehoods Developers Believe About Time (Score:2)
Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and "smear" the extra second across these twenty hours.
I wonder why they're "smearing" the time over 20 hours rather than 24, which would seem the more obvious solution.
Re:Falsehoods Developers Believe About Time (Score:5, Informative)
Because that's how they did it before and they consider it "safer" in the context of not making uneccessary changes this soon to the leap second. In the future they plan to do it 24 hours in advance:
Source: https://developers.google.com/time/smear [google.com].
Re: (Score:2)
Re: (Score:3)
Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and "smear" the extra second across these twenty hours.
I wonder why they're "smearing" the time over 20 hours rather than 24, which would seem the more obvious solution.
Metric
Smearing that number between 0 and 1... (Score:2)
We used to call this fuzzy logic back in the 1980's.
https://en.wikipedia.org/wiki/Fuzzy_logic [wikipedia.org]
Well actually... (Score:5, Funny)
*pushes glasses up* *straightens pocket protector*
Actually, they would need to run the clocks 0.0013889% slower. If ran the clocks 0.0014% percent slower, they would gain 1.008 seconds instead of just 1 second even.
Hire me Google. I'll save the internets for you.
Re: (Score:2)
This is the post we've been looking for! A+++++++++++++++++++++
End dream sequence.
Are you the Universal Migrator?
Re: (Score:2)
And here I thought I was the only one who listens to that weird stuff.
Re: (Score:2)
Tired of this shit. (Score:5, Interesting)
Re: (Score:3, Interesting)
Re: (Score:3)
Re:It's not that easy (Score:5, Insightful)
It's funny to me that they say the Earth's rotation is "determined" by IERS. No, it is *measured*. A subtle implied difference, but a critical one. The problem here is actually with unix time, not UTC. TAI as an alternative to unix time actually makes pretty decent sense. When was the last time you manually converted from seconds since epoch to day/month/year?
I think the point is that since time zones are actually updated more frequently for political purposes than leap seconds occur, it makes sense, for network-connected computers at least, to just stuff the leap seconds in the same distribution channels (already done actually) and abandon trying to hack around the clumsy (non-monotonically increasing) definition of unix time.
Re:Tired of this shit. (Score:4, Insightful)
Re: (Score:2)
Let enough accumulate and they'll be useful to everybody.
If they're really ruining your omelettes, there's two pseudozones without them - TAI and GPS.
Re: (Score:2)
You're forgetting navigation. 4 seconds to the nautical mile. Don't let UTC drift more than a second.
Re:Tired of this shit. (Score:4, Insightful)
Re:Tired of this shit. (Score:4, Insightful)
There are mods to ntpd and the time conversion libraries that do this. System clock is in real seconds since epoch, you only need to worry about leap seconds when converting between system clock and display (wall) time, which also handles time zones and leap years and everything else weird. Anyone who is dividing by 86400 to convert system clock to years, days, hours, minutes, seconds is doing it wrong. You can still divide by 86400 (or 3600 or 60) to display roughly how many hours, minutes or days a particular interval was, of course.
NTP could support this, or an auxiliary protocol defined, to distribute time conversion table changes (so with leap seconds as well as legal changes to daylight savings or other time zone changes), and to update the current difference between TAI and UTC. This would be useful even if we end up dropping DST or leap second adjustments.
Currently TAI and UTC differ by 36 seconds. For "current time", simply having that value available is sufficient for most applications that don't store the system clock value, and any that do are most likely already using a proper time conversion library.
Simply adding the ability to retrieve the clock as either "unix time (UTC-based)" or "elapsed time (TAI-based)" and convert between the two and use either as input to the time conversion routines would make it simple to update existing programs and databases. At the same time, converting once and for all to a 64-bit signed time value for seconds would help immensely with the next big time-handling crisis in about 21 years.
I fear that Google is just papering over the problem and making things more difficult to properly solve.
Re: (Score:3)
You really want a higher resolution than microseconds. The clock_gettime() system call returns the number of seconds and nanoseconds in two separate values. If you return the number of nanoseconds in a 64-bit signed value, you have a range of only +/- 292 years, which is limiting if you want to use it for historical dates or longer term future dates.
With a 64-bit signed seconds value you can go +/- 292 billion years. With a 64-bit value for the fractional part, you could easily increase the resolution to
Re: (Score:2)
With a 64-bit signed seconds value you can go +/- 292 billion years. With a 64-bit value for the fractional part, you could easily increase the resolution to attoseconds (1E-18, 60 bits). Both those limits are not very constraining.
Sure, you say that now, but when it comes time to fix the Y2.92×10^6K bug, are you willing to pay for it?
Re: (Score:2)
Your arrogance wreaks of someone who has never served in the military
You mean it wreaks(sic) of a sane person?
particularly in a combat role.
How is that anything to be proud of. If you did that, it only shows that you're dumb, expendable and probably wouldn't have contributed to society in any constructive way anyway.
That said, how does any of this matter to TAI vs UTC, my dear mil-grade potato?
O cursÃd spite (Score:2)
Re:O cursÃd spite (Score:5, Funny)
Leap Seconds (Score:3)
A smeared second is stupid IMHO. People have had since 1973 to put leap seconds into their software. However, this is how NTP does it, so many computer clocks will have a smeared second even if they don't use Google.
UTC with leap seconds was set up to support celestial navigation. You can still take out your sextant and determine your position to a km or so using standard clock time. There is still a feeling that that is a useful attribute.
My personal feeling is that the Internet should just adopt TAI, but I have never gotten anywhere with that proposal.
Instead, this will go on until some plane crashes or rocket explodes or there is a massive exploit* due to a leap second being incorrectly handled, and then this will be fixed.
* There are some security protocols that make implicit assumptions about the time being roughly coordinated. On leap second day, those assumptions may be false,
Re: (Score:3)
Are you really claiming that "roughly coordinated" is at much less than 1 second resolution? If I understand correctly the maximum discrepancy would be half a second to occur at the actual point that the leap second is applied plus any normal deviation of the time systems. For most applications this is acceptable. Anything that is failing to fly or exploding due to this level of difference in time has bigger problems than the time servers being slightly off and is an accident waiting to happen. It wou
Majority rules (Score:2)
If I were someone who actually cared about seconds and depended on high resolution timekeeping this would undoubtedly strike me as a really shit-headed idea.
"Smeared"? (Score:2)
Caveat sysadmins (Score:2)
Re: (Score:2)
"Only Trump made that extra second for Americans possible!"
or
"A typical smear campaign by Trump supporters!"
Pick your side.
FUCK 2016 (Score:2)
Just when we were starting to get to the last month of this AIDS-filled dumpster fire of a year, the go and add another goddamned SECOND to it.
I usually don't say things like this, but in this case, FUCK YOU, SCIENCE!
You know what's going to happen, they're going to start dropping Dick Clarke's frozen head in Times Square, and it's never going to reach the bottom. It will be the end of time and it will always be 2016, FOREVER.
good news everybody! (Score:2)
Re: (Score:1)
Trump voters like Samsung smart phones and Hillary voters like iPhones. One explodes on Twitter, the other is business as usual.
http://www.wsj.com/video/trump-voters-like-samsung-clinton-voters-like-apple/73985F23-0029-4B38-BC3A-EE6CEF33C69C.html [wsj.com]
Re: (Score:2)
Interesting. I hate them both and use a Moto Droid.
Re: (Score:1, Offtopic)
But can I app a Trump, or can I only Trump an app?
Can you trump Trump's app?
Re: (Score:2)
I don't know about apps or luddites. I do know that Trump and cows generate methane.
Re: (Score:1)
I had a spare second to waste.
But was it smeared or unsmeared? Enquiring minds want to know!
Re: (Score:3)
Let's just slow that down. Hope that wasn't important. What is 0.0014% between friends?
Friends that do low-latency high stake stock trading may have issues if some of competing parties run on a skewed clock (or syncs with something that syncs with something that runs on a skewed clock) and others don't. That affects not only the latency, which is important enough, but as the skew increases until the end when the leap seconds kicks in, and because the leap second is added at midnight UTC while bourses around the world are offset from that, it could mean that some might get a large part of a
Re: (Score:3)
Re: (Score:2)
I suspect very few here will any any sort of sympathy for people who do low latency stock trading.
That's short-sighted thinking. Low latency traders exist, whether we like them or not[*], and it does not affect just the traders, but the stocks they trade, the companies, and other stock holders not involved in low latency trading. Their ability to do harm to others is affected when the playing field shifts, giving advantages to some. They're at war with each other, and the playing field being level helps maintain status quo, and prevent stocks from crashing or soaring when they shouldn't.
[*]: I too t
Re:Hey look the flow rate is a little high. (Score:5, Insightful)
Just make the stocks trade in time-coordinated batches. The batches can still be relatively fast - even every second - just so it is slow enough to stop the stupid games with the speed of communications.
Re:Hey look the flow rate is a little high. (Score:4, Insightful)
Every trade that occurs within a given interval (I think 1 second is too short still, maybe a minute... or 1/4 hour, since that's often how long quotes are delayed for the average trader) trades at the same price for a given transaction type. The net effect on the market would be the same, we just wouldn't have, for example, two people placing SELL orders for a million shares of something at $100/share and one of them getting $190/share while the other only gets $10/share, which does currently happen.
Re: (Score:3)
How will you decide on order priority within the one-second batches? Price/time priority? Favours people with fastest connection as they can quote beyond the price they would be filled at when the batch trades and pull their quotes at the last moment if the market moves against them. Price/volume priority? Favours the bigger players who are pushing bigger orders around as well as people with faster connections. That's just two simple, obvious disadvantages to running mini auctions like this. If there
Re: (Score:2)
How will you decide on order priority within the one-second batches?
I wouldn't do it - people who do this sort of thing for a living would. If I'm just spitballing and you won't make fun of my naivety I could try to come up with some solutions. I'm not sure why FIFO wouldn't work just fine - simply fill the buffer until the next transaction window fires. It's the same system that is in place now, with larger quantum steps.
Re: (Score:2)
I actually do this for a living, and I'm telling you that 1-second intervals would make the market less stable and more prone to price fluctuations. This would make the effective transaction costs for investors higher and put more money into the pockets of market makers. But sure, if that's what you want to do, pressure your market regulators for a change like that. It's more money for me in the end.
Re: (Score:2)
Before you go for my throat, I was simply proposing a way to put the kabash on low-latency stock trading. I don't actually have a strong aversion to it, and though I'm pretty ignorant about the whole thing tend to agree with you. But if stopping the low-latency guys is your goal, it's pretty straightforward.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
No they don't. The clock is quite unimportant for the HFT crowd. All they care and look at are the incoming orders and changes in price, the importance of the clock is only important for later record keeping by firms allowing clients to trade via their accounts (aka stock brokers) since they have to prove to the authorities later that they gave their clients the best price available at the time from the various exchanges that they trade on but that is also not a problem since you then simply aggregate the l
Re: (Score:3)
If your work depends so precisely on timing, then you should be handling your own timekeeping.
No, the concern isn't whether your time is correct, but whether it is the same as the time others use.
That is not solved by adding an atomic clock. In fact, it might make it worse.
Re: (Score:2)
Handling your own timekeeping doesn't necessarily mean having your own atomic clock. In this context, it means deciding on who has the canonical clock and syncing with it.
Google is explicitly saying they are not serving UTC, so if your trading partners are on UTC, you're an idiot if you sync to Google.
Re: (Score:2)
But that's the problem - you can decide who you sync with, but you cannot decide who others sync with.
A time discrepancy is a problem in either case.
The most obvious solution is that the bourses should provide time synchronization, and that everyone else sync to their time, right or wrong.
Re: (Score:2)
Exactly. If you are part of a group making financial transactions, that group needs to decide on a canonical time source. And yes, it's relation to the rest of the world is irrelevant to the transactions.
In any event, all time sources are wrong to some degree. If you're using NTP over the internet, you will perhaps keep the error below a tenth of a second. A directly attached GPS clock will keep it closer but the error will remain non-zero.
Re: (Score:3)
Android, or even your desktop OS aren't the point. You are correct that consumer level devices have no problem "fixing" their clock by a second when they discover it. The problem is when you have tons and tons of real time transactions that have to be kept in a very precise order. How do you easily and reliably determine which event happened first if the numerical timestamp isn't sequential? Smearing the second ensures that timestamps, of any precision, remain sequential. This can be crucial for some of the
Re: (Score:2)
You use a unique, sequential value independent from timestamp, I'd hope.
Re: (Score:2)
If the servers can't sync within a full second, we should give up on NTP entirely.
Many things require far more precise timing than that.
Re: (Score:2)
Hey, if you know how to run large internet connected systems better than Google, maybe you should step up and compete. As obviously you think they're clueless about such things and you know better.
I look forward to all your new systems that make Google obsolete.
Re: (Score:3)
>All that will happen is that one second your computer will think it's on time, and a couple seconds later your computer will think that it's a second behind and correct itself against the NTP server.
The problem here is that not all systems adjust at the same rate. So once all the systems are a second off, they will all be slightly out of sync with each other as they skew their clocks until they're all correct again.
For us, clocks being under a second out of sync is not a big deal. But for software that
Re: (Score:2)
That's actually fairly close to the do-nothing approach used by default. When you run ntpd, it periodically checks th time and used adjtime, adjtimex or some equivalent to slew the clock as needed to get back in step. It does nothing special with the leap second flag since the system clock has no way to handle it anyway. After the leap second, the NTP client notices that the system clock is 1 second fast and so slews it back one second.
The clock slew is done by slowing the clock just a bit so it continues t
Re: (Score:2)
Somehow I doubt industrial equipment is tied into Google's NTP servers. But Google began doing this with their NTP servers back in 2011, and as far as unix servers go, there have been no issues with previous "smearing" so I don't expect any issues with this next leap second either.
Re: (Score:2)
Right this is about Google. Not my servers, or your servers. I suppose someone could unwittingly be using a Google NTP server unawares.
Re: (Score:2)
Really? You think getting every program on the planet that that interacts with Google's time servers to reliably handle a minute with 61 seconds without any ill effects is simple?
Meanwhile, very little software, even time-sensitive software, has has any concept of real time, only clock-time, so making the clock run very slightly slower accomplishes the same thing while making everything look like (very slightly faster) business as usual, with the only potential conflicts coming from slight ( 1 second) inco
Re: (Score:2)
Good point, I stand corrected.
Re: (Score:2)
To be even more clear, every clock on the planet is constantly providing inaccurate time, since we've established a very precise standard unit of time (the second) that bears only an approximate relationship to the non-constant physical phenomena that originally defined it (1/86,400th of a mean solar day)
Re: (Score:2)
Historical definition of second is irrelevant. Current time standards (TAI, UTC) are defined in terms of the current definition of second. If a clock reports time sufficienty near to appropriate time standard, then it is by definition correct.
Re: (Score:2)
Well, that is kind of the point of the leap seconds - to compensate for just such unpredictable changes in the Earth's rotation...
Re: (Score:2)
NTP Pool is there for a reason.
Re: (Score:2)
If you're that worried, change your accepted settings.
But you're talking crap, as my NTP pool server gets PUSHED OFF the pool if it drifts anywhere near that far, or goes offline for even a short time.
Currently my jitters for uk.pool.ntp.org are:
0.071
0.079
0.050
0.190
Those numbers are IN MILLISECONDS. 0.05 of a millisecond.
And 0.478 on a stratum 1, famous, advertised, academic, public NTP server not in the pool.
Re: (Score:2)
Or you could use the USNO [navy.mil], the other official time reference for the United States.
Re: (Score:3)
Re: (Score:2)
It's actually closer to the correct implementation - leap seconds are the technical solution to try and get us back closer to the correct time. Making seconds marginally longer is actually more accurate.
Re: (Score:2)
Except that a second is defined in terms of [what is emitted by] a phase transition of some particular element, or possibly in terms of the speed of light. Neither of which cares or has anything to do with Earth going around the Sun, and spinning around its own axis.
So "more accurate" is wrong. It will conflict with everything that does not both a) smear time and b) smear time in the exact same way google does.
Re: (Score:2)
The defacto non-solution does much the same thing to the system clock after the leap second in order to correct for suddenly being 1 second fast but maintain monotonic time. That is, adjtime (or adjtimex) gets called to slew the clock.
In many cases, the defacto non-handling is the right thing to do. Although it compresses events very slightly, it maintains causality in the system logs and such.
Re: (Score:2)
If the system is time sensitive. Say like some sort of GPS system, where if the time is a little slower then your calculations may be off.
Re: (Score:2)
The question was if there could be a problem with Smeared Time.
I have an answer. It probably isn't the best solution to the problem, but it is a problem that exists.
Re: (Score:2)
With 20 hour smearing you get that for ~10 hours (i.e. significant time interval) time on synchronized computers would be more than 1/2 sec (i.e. human-noticeable difference) from correct value. That is substandard quality for time synchronization.
Re: (Score:2)
That's not POSIX compatible.