back to article Google turns on free public NTP servers that SMEAR TIME

Google's turned on a set of public network time protocol (NTP) servers. You'll find the servers at time.google.com – which resolves to 216.239.35.0, a rather less pretty IP address than the 8.8.8.8 and 8.8.4.4 Google uses for its public domain-name system (DNS) servers. There's also time2.google.com at 216.239.35.4, time3. at …

Silver badge

is this fake news

or just another smear campaign?

12
0
Bronze badge

Smearing

Huh, I thought the easiest method would've been:

23:59:55

23:59:56

23:59:57

23:59:58

23:59:59

23:59:59

00:00:00

0
3

Re: Smearing

So did everyone else, then everything crashed when the same second happened again and some really weird things clashed.

10
0

Re: Smearing

That can make things get really confused also, so it's a tricky one to be sure.

If you for some reason have something running at 23:59:59; and you check if it's running still 1 second later (expecting the time to be 00:00:00) - what do you expect will happen?

3
0
LDS
Silver badge

Re: Smearing

No, it could create problems to some very time-sensitive applications.

0
0
Silver badge

Re: Smearing

What about sub-second units?

Taking it as you have said, for events which are timed at the milli/microsecond level, you could have an event which occurred after another appearing before it. Or else, you would need to either "smear" that last second, or repeat the final milli/micro/nano/picosecond.

The "smearing" approach is probably the most sensible method in the vast majority of cases.

0
0
Silver badge

Re: Smearing

The "smearing" approach is probably the most sensible method in the vast majority of cases.

You mean for those code monkeys who don't know/don't care and don't test?

First point - your software should not crash if time is stepped anyway, what happens then if a machine is off-network for a while and then adjusted to the correct time (manually or by NTP)?

Second point - if you depend on precise time then do it properly! This is not a new issue, it has been documented and implemented in sane systems since the late 1970s. And for those who really need continuous time-scales (e.g. for computing time differences that are correct in any absolute sense) we already have TIA or even simpler GPS time.

2
2
Silver badge

Re: Smearing

"Second point - if you depend on precise time then do it properly!"

Always a bold claim until you're told the budget given to the job.

6
0
Bronze badge
Happy

Re: Smearing

How the heck to do test a leap-second event from NTP?

1
0

Re: Smearing

Just use a private NTP server - have a couple that lock to GPS with rubidium reference oscillators, have one that has been nobbled so the precise 1 pulse per second is derived directly from the GPS receiver - the NMEA data from the receiver is intercepted - can then give false data and leap second flags to the server (SyncServer S200 )

( Just don't let it out of your network ! not that a good NTP client should ever be happy with a single stratum 1 server - so would soon spot a problem -- had this in the past with Microsoft servers hat supposedly had an NTP service running - but as they don't use hardware interrupts but software - the clients all rejected them as they jittered excessively - so where flagged as illegitimate servers and blacklisted ! )

1
0
Silver badge
Facepalm

Re: Smearing

You don't use the calendar time set by NTP for anything other than human readable output, any program that is remotely sensitive to time differences should be using the monotonic API, which is just a value incrementing at a constant rate and completely unaffected by leap seconds or any other adjustment to the calendar time.

1
0
Anonymous Coward

Re: Smearing

"Huh, I thought the easiest method would've been:

23:59:59

23:59:59

00:00:00"

What could possibly go wrong?! Oh, wait...

Leap second bug cripples Linux servers at airlines, Reddit, LinkedIn

http://www.theregister.co.uk/2012/07/02/leap_second_crashes_airlines/

1
0
Silver badge

Re: @Missing Semicolon

How the heck to do test a leap-second event from NTP?

By the power of Google searching, first on the list:

http://support.ntp.org/bin/view/Dev/LeapSecondTest

Or if you are looking for an easy to deploy commercial solution:

http://blog.meinbergglobal.com/2015/02/25/leap-second-test/

0
0
Joke

Re: Smearing

"Second point - ..."

So was that on purpose, or just accidental? Either way, pretty funny, and "its about time" someone made that crack.

0
0
Silver badge

Frustration

What makes this all very frustrating is that there's already perfectly good solutions to the leap second problem.

If OS developers wrote their OSes to use International Atomic Time instead of UTC as their base timescale, the OS would never need to deal with a leap second.

And there's perfectly good libraries for converting TAI to, e.g. UTC that already handle leap seconds, can do accurate time calculations, etc. One such example is the SOFA library from the IAU.

Like everything else it cannot predict leap seconds, but an OS is already well placed to receive library updates as part of its regular maintenance. Why not this one too? And if every developer used TAI instead of UTC to represent time values then all their calculations would always be correct, with conversion to UTC for display being the only thing that'd be wrong in the absence of updates.

9
3
Silver badge

Re: Frustration

All sane OS already handle the leap second properly, except when some code monkey changes it and does not test it, and NTP has this built-in (it announces the leap 1 day in advance so the kernel can step as needed without an NTP packet at the precise change point).

No, this is simply a sop to shitty coders who do not understand the basics of precise time-keeping that have been this way for 40 odd years. I.e. for longer than most of them have lived.

6
1
Silver badge

Re: Frustration

"Like everything else it cannot predict leap seconds, but an OS is already well placed to receive library updates as part of its regular maintenance."

Unless the OS (like XP and earlier) is at EOL. Or the OS is meant to operate in a fixed, non-upgradeable capacity such as an embedded device?

0
3
Silver badge

Re: Frustration

"Unless the OS (like XP and earlier) is at EOL. Or the OS is meant to operate in a fixed, non-upgradeable capacity such as an embedded device?"

You mean the same devices that have been working with leap seconds for years and years now? Lets face it, Windows default is to update the time using SNTP once per week! So it steps time every week and your system just get on with like. So what is the beef about a correctly applied 1 second step every ~18 months?

5
0
Facepalm

Re: Frustration

There's got to be some sort of pun somewhere about Second Guessing...

1
0
Gold badge

Re: Frustration

"If OS developers wrote their OSes to use International Atomic Time instead of UTC as their base timescale, ..."

At least according to the documentation, Windows has used "seconds since 1601" as its base timescale for the last twenty years and UNIX has used "seconds since 1970" for rather longer. It has always been my impression that a conversion to UTC is purely a user-interface thing for the benefit of meatware. Any programmer baking Babylonian time-keeping conventions into their design really needs whacking over the head with a two-by-four clue-stick.

0
0
LDS
Silver badge

We have also a Google time now?

Shouldn't Google NTP servers be (enough) in sync with any other NTP server, referencing all of them reliable time sources? I'm syncing directly with my national institute which is in charge of reference time.

4
0
Silver badge

Re: We have also a Google time now?

Google could well have added its servers to the NTP time pool, which was established to make it as simple as possible to establish a time base. There's the baseline pool.ntp.org, and if you need a narrower scope, simply prepend your two-character country code (like us.pool.ntp.org).

As for other options, that depends on where you are. For example, WWV (the US clock radio station our of Colorado) is tricky to pick up east of the Appalachians, especially during the day.

2
2
Silver badge

Re: We have also a Google time now?

Google could well have added its servers to the NTP time pool

No, no, and thrice no! Because Googles NTP servers will be telling the wrong time for about a day after every leap second.

Now you might not care, and many others don't case, because all they want is some sort of time-of-day indicator. But heaven help you if you need millisecond or better accuracy for anything like financial HFT, log file forensics or any number of science applications.

4
0
Anonymous Coward

Re: We have also a Google time now?

There's also the simple fact that it's Google, and I don't even want to give them a ping that I'm interested in accurate time (you probably guessed from that I'm not using their DNS either :) ).

Actually, I'd be confirming to them that I'm clueless, because the whole time infrastructure relies on everyone doing the exact same. Google doing its own with something so seriously critical instead of collaborating with a large, globally established infrastructure with established processes and protocol for adjustments is only going to cause problems for the people that fall for it.

I rather draw stabilised NTP from a number of pool.ntp.org elements or GPS than Google, thanks. I need to keep things running, which means staying compatible with a collaborative approach.

I don't have time for this :).

5
0
Silver badge

Re: We have also a Google time now?

Google are doing their own thing internally, and have been doing so for a while.

Now that others have access to the Compute power in their bit barns they need a way to sync time between their on and offsite resources, and running GoogleTime (tm) seems like a sensible option. I'd still suggest pool servers for most people, but for those with ties into the Google systems that need accurate sync (not necessarily time, but sync) then this is a good solution.

For a normal home user then the conventional approach of a leap second actually doesn't work too badly - we do seem to have leap seconds figured out reasonably well...

Having computers run on a non sidereal dependant clock does seem like a good idea though...

1
1
Silver badge

Re: We have also a Google time now?

"Now you might not care, and many others don't case, because all they want is some sort of time-of-day indicator. But heaven help you if you need millisecond or better accuracy for anything like financial HFT, log file forensics or any number of science applications."

If your application is SO time-sensitive as to require BOTH precise AND accurate time to less than a second (in the case of HFT, to within 1us), then you can probably justify the expense of your own authoritative time source.

4
0
LDS
Silver badge

Re: We have also a Google time now?

Now you can get GPS (or any other similar service) receivers for time synchronization. Today, I'd would use them with a proper antenna to ensure good data even if signal goes through bad weather.

1
0
Silver badge

Re: We have also a Google time now?

The problem there is that GPS signals can drift due to atmospheric interference (that's also why your GPS fix tends to drift even when you stand still). They're only good for casual time synchronization, in which case if you have an internet connection, it's easier to just sync to a time pool since the connection's so terse even a dialup connection can handle it.

For high-precision, high-accuracy demands, you're probably going to need your own source for consistency.

1
0

Re: We have also a Google time now?

The atmospheric drift leads to 10s of nanosecond level errors, which are way less than the impact of variable internet delays. That's what many stratum 1 NTP servers use GPS references, as do many mobile base stations.

2
0

Re: We have also a Google time now?

As a 1st approximation, 1m of positional error is equivalent to 3ns time error (based on speed of light). So if you GPS location is good to 10m, the receiver knows UTC to better than +/- 30ns

2
0
Silver badge

Re: We have also a Google time now?

You forget (1) the speed of light is inconsistent in atmosphere and is usually some fraction of c, and (2) you tend to have multiple samples of varying consistencies, including consistently OFF TARGET.

1
0
Silver badge

Re: We have also a Google time now?

the speed of light is inconsistent in atmosphere

That is why the military GPS used two frequencies, to compensate for ionospheric electron density effects. You can get the same with newer systems like Galileo and from differential GPS, etc.

But if you need us or better time its a challenge for the OS, etc, to respond and stamp the network packets with sufficient stability. For that sort of job you use PTP instead:

https://en.wikipedia.org/wiki/Precision_Time_Protocol

1
0
Silver badge

Re: We have also a Google time now?

"Google could well have added its servers to the NTP time pool

No, no, and thrice no! Because Googles NTP servers will be telling the wrong time for about a day after every leap second."

I think the assumption in this is that Google could have done that and then implemented the leap second along with everyone else instead of having the Google Second.

0
0
Joke

Hang on a sec

With all the suggested variations in how to handle this, I sense a rift in the space time continuum

4
0

Suggested to Google by...

Tim Cook.

Happy New Year iCalendar.

1
0
Silver badge

Unix/Linux has ALWAYS handled a minute with 61 seconds in it

The 'struct tm' that holds time in year, minutes, seconds, etc. has allowed tm_sec to go from 0-60 (instead of 0-59) for this very reason since before I first touched Unix 25 years ago, and presumably from day one for Linux. So Android and iOS should be perfectly fine. As for Windows, who the hell knows?

Now some applications may not be coded properly to expect that extra second and get a tm->tm_sec == 60, but this is hardly the fault of the OS, it is the fault of the application!

7
0
Joke

One second?

So we're getting a rebate of one miserable second. What about our eleven days?

4
0
Silver badge
Boffin

Sub-second accuracy

I'd suggest if you've got something that critically relies on sub-second accuracy then you shouldn't be relying on the OS clock and NTP.

If you don't have your own counter, at the very least you need code to handle fluctuations in the length of a second because all sorts of things can affect the clock cycles of off the shelf hardware running off the shelf OS's.

1
0
Silver badge

Re: Sub-second accuracy

Depends on what you mean by " sub-second accuracy" so NTP over WAN is usually better then 10ms, or LAN usually of the order of 1ms.

1
0

Re: Sub-second accuracy

That's not correct. Google use this for their NoSQL solution. Update one comes in a 11:42:10.100 and update two comes into a different server at 11:42:10.102 - so update two wins in the eventually consistent model. If they don't do the time smearing, then events can get out of order and applications end up having incorrect data.

You may not agree with the approach of using smeared NTP over their large numbers of servers to perform this but it works very well for them and they seem to have managed distributed transactions better than almost anyone else.

1
1
Silver badge

Re: Sub-second accuracy

From what I've read, HFT requires times precise AND accurate to within 1us.

1
0
Silver badge

Re: Sub-second accuracy

"If they don't do the time smearing, then events can get out of order and applications end up having incorrect data."

AFAICS they could still order events by using a 61 sec minute.

0
0
TRT
Silver badge

Erm...

Doesn't the usefulness of this depend on how your NTPD is configured?

3
0
Silver badge

Instead of another work-around we need to fix the underlying problem.

All it needs is for the Earth's rotation to be speeded up slightly then it would always agree with UTC. I suggest we make all joggers run westward.

0
0
Anonymous Coward

Re: Instead of another work-around we need to fix the underlying problem.

Nah, just get Space X to point the exhaust of its rocket testing facilities in the right direction. A couple of boosts from that ought to do it.

0
0
Silver badge

Re: Instead of another work-around we need to fix the underlying problem.

You may need a larger number of joggers than you expect.

https://what-if.xkcd.com/26/

0
0
Silver badge

Re: Instead of another work-around we need to fix the underlying problem.

Well, since the problem is due to the effects of tides caused by the Moon, take the military option and Nuke the Moon!

"We stand today on a great threshold of History. After this war with Luna, the lunanites will no longer be able to steal our precious Earth's rotation! >click<."

0
0
Thumb Up

I gave up on the NTP pool servers and what not - use the real thing:

NPL time servers

Delay is down to about 18ms and jitter is around 3 ~ 5. Using NTP pool servers, delay could be up to 40ms and jitter all over the place.

0
0
Silver badge

Like I've said, give or take a second is OK for casual time synchronization, plus you have to consider the contention of the Internet itself when considering the precision of your responses. Beyond 1s precision probably requires a dedicated time source.

0
0

"Beyond 1s precision probably requires a dedicated time source."

I see a theme here - 60's[ec] ~ dedicated follower of fashion == Google!

0
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017