Slashdot Mirror
Google's New Public NTP Servers Provide Smeared Time (googleblog.com)
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 that my DPS will be slightly higher on December 31st?
My eyes reflect the stars and a smile lights up my face.
Google has been smearing leap seconds over NTP since 2011. This is a public reminder that Google NTP will be serving smear seconds because there is one coming.
"don't mix smearing and non-smearing time servers"
Best Slashdot Co
At 4.37 it'll report that 4.38 molests goats. 4.38 will retaliate by claiming 4.37 killed a man and lied about it. 4.39 will accuse 4.38 of secretly having two wives who know nothing about one another. 4.40 will claim 4.38 and 4.37 are having a secret affair and are making up allegations about one another to hide the fact. 4.41 will claim 4.40 is a multiple felon. 4.42 will accuse 4.41 of cheating on his taxes...
You are not alone. This is not normal. None of this is normal.
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.
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 second more than others at cutoff time, which is an eternity in this context.
*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.
Can we just move to TAI and convert to UTC only when interfacing the meatspace?
Geez, foiled by Slashdot's non-UTF8-ness again.
Bruce Perens.
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 these large real-time organizations.
The only other somewhat practical solution is to implement it like we do leap years, however as leap seconds are not as predictable, you run the risk of whether every system has the correct version of the database with the leap-seconds enumerated, and add extra computing resources on every translation to human readable formats. Google correctly points out that no current consumer OS currently has this capability, and you'll find that data-centre OSes are generally the same. While Google can control one or two of those, they can't guarantee that every device they send something to will also support it.
The leap second smear is a very elegant solution to a real, and somewhat complex, problem.
It's really hard to come up with a scenario in which the problem that leap seconds solve actually exists.
I am TheRaven on Soylent News
I suspect very few here will any any sort of sympathy for people who do low latency stock trading. Some even suggested to add time skew or random jitter to stock tickets precisely to prevent this sort of trading.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Smeared seconds come after sloppy seconds.
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
I browse on +1 so AC's need not respond, I won't see it.
>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 has to be well synchronized between hosts, it's a huge deal. So it's better to do it Google's way to keep their infrastructure working reliably.
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...
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.
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,
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.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
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.
This.
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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 was a simple solution, it would've been done already.
Some exchanges do implement technical measures to try and reduce gaming. For example KRX enforces fill ratio - there's a minimum proportion of your orders that must actually trade or you'll be penalised. This means you can't sit around placing orders and cancelling them all day with no intention of executing. But on the other hand, it means you can't readily quote, displaying an order at the price you're prepared to trade given current market picture and moving it when the market moves. This makes it harder for an investor to know what price they can actually get executed at, and leads to a silly game of trying to hit attractive orders as quickly as possible. So it still makes life harder for actual investors and favours the guy with the lowest latency price feed.
The main reason for the latency wars is just because margins are so thin. In the past, spreads were tens of cents. A market maker (back then typically one of the big brokers or investment banks) made tens of cents against the theoretical fair price on every security traded. Lower latency allows quoting tighter spreads (you can move quotes quicker if the market moves against you), so the market makers are making far less money per trade - only a few cents per security minus exchange fees and government taxes on every trade. Because the profit per trade is really low, it's a cut-throat competition to get as many profitable trades as possible.
FFS I'm not doing anything requiring microsecond accuracy if it's within one second or less then it's fine, and unless you're running some sort of mission-critical operation that requires precise alignment to the atomic clock for some reason, you should probably just take your meds and calm the hell down about it.