Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Google Programming

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.
This discussion has been archived. No new comments can be posted.

Google's New Public NTP Servers Provide Smeared Time

Comments Filter:
  • by The-Ixian ( 168184 ) on Thursday December 01, 2016 @10:49AM (#53401293)

    Does this mean that my DPS will be slightly higher on December 31st?

    • by Diss Champ ( 934796 ) on Thursday December 01, 2016 @10:53AM (#53401315)

      That depends largly on whether you play better or worse while drunk. The NTP server tweak will be a secondary effect at best.

    • by Anonymous Coward on Thursday December 01, 2016 @10:55AM (#53401323)

      Does this mean that my DPS will be slightly higher on December 31st?

      No. It means you'll lose a second of uptime.

      • 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.

    • by fisted ( 2295862 )

      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.

  • by Anonymous Coward on Thursday December 01, 2016 @10:56AM (#53401335)

    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 come after sloppy seconds.
      • No, smeared seconds is the anal equivalent of sloppy seconds. Great if you like the extra lubrication.
    • by lgw ( 121541 )

      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.

      • by jaa101 ( 627731 )

        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.

  • by wiredog ( 43288 ) on Thursday December 01, 2016 @11:03AM (#53401371) Journal

    "don't mix smearing and non-smearing time servers"

    • "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.

    • 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!

  • by squiggleslash ( 241428 ) on Thursday December 01, 2016 @11:04AM (#53401379) Homepage Journal

    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...

  • by Anonymous Coward

    Jesus Christ, this sounds like an April Fool's joke.

  • 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.

    • by heypete ( 60671 ) <pete@heypete.com> on Thursday December 01, 2016 @11:31AM (#53401551) Homepage

      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:

      Although we decided it would be safest for Google's infrastructure to handle the 2016 leap second using a 20-hour smear, the same way we handled the leap seconds in 2012 and 2015, this is not the only smear that works well. Many organizations use smeared clocks, and it would be helpful if the smears were the same. After all, the purpose of clocks is to read the same time in different places.

      We would like to propose to the community, as the best practice for leap seconds in the future, a 24-hour linear smear from noon to noon UTC. We plan to use this smear starting from leap second #38, which is likely to be in 2018.

      Source: https://developers.google.com/time/smear [google.com].

    • by creimer ( 824291 )
      Using the number 10 probably made the calculations more easier to figure out on the back of a napkin. What's obvious is not always simpler.
    • by EvilSS ( 557649 )

      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

  • We used to call this fuzzy logic back in the 1980's.

    https://en.wikipedia.org/wiki/Fuzzy_logic [wikipedia.org]

  • by watermark ( 913726 ) on Thursday December 01, 2016 @11:37AM (#53401597)

    *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.

  • Tired of this shit. (Score:5, Interesting)

    by LTIfox ( 4701003 ) on Thursday December 01, 2016 @11:41AM (#53401633)
    Can we just move to TAI [wikipedia.org] and convert to UTC only when interfacing the meatspace?
    • Re: (Score:3, Interesting)

      by LTIfox ( 4701003 )
      I mean, we have timezone stuff already - just bury those seconds in those tables. Run machine clock at TAI and calculate "local time" by adding, for example, 8hrs35seconds to whatever local timekeep says.
    • by TheRaven64 ( 641858 ) on Thursday December 01, 2016 @12:23PM (#53401913) Journal
      Given that Terrestrial Time exists for astronomers, and the only people for whom leap seconds are useful are astronomers, can we just stop putting leap seconds into UTC?
      • 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.

      • by jaa101 ( 627731 )

        You're forgetting navigation. 4 seconds to the nautical mile. Don't let UTC drift more than a second.

    • by Xylantiel ( 177496 ) on Thursday December 01, 2016 @01:37PM (#53402503)
      The problem is not so much with UTC but with unix time [wikipedia.org], as POSIX and NTP have conflicting conventions for handling leap seconds. Well and Google NTP has yet another convention. But the spirit of what you say is correct, we should probably abandon unix time as the fundamental representation on computers in favor of TAI. Software already has to consult a timezone database to convert to local time anyway, why not also require that for conversion to UTC too (to get the leap second offset from TAI).
      • by tricorn ( 199664 ) <sep@shout.net> on Thursday December 01, 2016 @06:18PM (#53404549) Journal

        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.

  • I can't ever see a story like this without thinking "O cursÃd spite".
  • by mbone ( 558574 ) on Thursday December 01, 2016 @01:28PM (#53402429)

    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,

    • by paraax ( 126484 )

      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

  • 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.

  • Couldn't they have used a nicer word than "smeared", like maybe "interpolated"? (See also other aversion-causing words: "moist", "crevice", "phlegm", "penetration", etc.)
  • Given the behavior of the "smearing", they are NOT NTP servers you want to use with hard real time systems, especially if 1 second will prang your gear.

"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972

Working...