UT1 NTP Time Dissemination | Hacker News Reader

UT1 NTP Time Dissemination

nist.gov

40 pointswglb24 comments

Open articleView on HN

> The reply will have no special indication that the transmitted time is UT1 and not UTC.

And this is how really terrible time situations occur.

Like when Google’s smeared leap second leaked into the general NTP pool?

Wait what?

https://developers.google.com/time/smear

For me at least the "wait what" was "when did the google smear leek into general NTP pools," not "what is the google leap second smear"

I think the question wasn't about whether Google smears leap seconds on their time service, which has debatable benefits and drawbacks, but rather about your use of "leaked" and "the pool". You should not mix smearing and non-smearing NTP services. I don't believe Google intentionally participates in any NTP pool projects.

I also don't believe google intentionlly participates in pool.ntp.org, but it would be easy for some of the pool servers to have one of google's public ntp servers in their static configuration. On days without a leap second, they're pretty good ntp servers.

Personally, I had servers configured with google and some other semi-public servers during the last leap second, and (traditional) ntpd did lots of weird stuff, so I ended up with pretty mushy time that day.

I have six servers in the pool, and I definitely leaked the Google time smear into the pool.

It's hard to get reliable upstream NTP servers--it was easier to point to Google. Google smeared, so my servers smeared, so all my downstream clients smeared.

I don't know how much my servers currently handle, but at one point they carried 1% of the North American pool NTP traffic.

Do you have any more detail of the leak event? My google-fu is failing me

One of my servers was incorrectly fed the Google smeared time via the NTP pool. Diagnosing it was delightful.

As I read, only two specific servers provide this -- ut1-wwv.nist.gov for example, is well labeled too. Its not clear if its part of the standard round-robin but the wording gives me the impression that it is not.

I wouldn't expect anyone to unintentionally use these two servers. But traditional ntp also publishes time, so it would be easy to propigate.

Since it's not identified as an alternate time scheme on the wire, there's no way for downstream ntpds to know and refuse ut1. Falseticker checks help, but don't eliminate the possibility of following the wrong clock.

In case you're like me and don't know what UT1 is https://en.wikipedia.org/wiki/Universal_Time#Versions

How bad an idea would it be to just use UT1 everywhere and forget about leap seconds?

It'd probably break something but I can't for the life of me figure out what.

TAI is the 'UTC without leap seconds'.

UT1 is an evolution of solar time, and wobbles when Earth does because it's using the Earth and Sun (and other bodies) as a clock.

UTC is TAI with leap seconds added when UT1 drifts too far away.

"UT1R" is a smoothed version of UT1 with the wobble removed.

I wrote an OS that used TAI as it’s time. All in all I was pleased with the outcome. UTC conversion happened at parsing and formatting, but those are relatively uncommon compared to comparison and interval addition so it works well performance wise.

Given that UTC is always within 0.9s of UT1, either TAI or UT1 can be considered "UTC without leap seconds" since the leap seconds in UTC are an attempt to reconcile the two.

It would be quite bad.

See this page: https://www.ucolick.org/~sla/leapsecs/dutc.html

And scroll down to "Implementing the plan outlined at Torino", taking note of the "Notable event" column.

Edit: I think I misunderstood your question. This table shows the results of what would happen if we just stopped adding leap seconds.

That would be the results of usint TAI, not UT1. UT1R might make more sense than either though.

Yeah I misunderstood the question. Still, it's a useful demonstration of why we need leap seconds.

Anything that cares about really small timescales would have issues. UTC and TAI seconds, microseconds, and nanoseconds are always the same length. UTC has leap seconds to account for the change in rotation of the Earth. TAI just doesn't care and keeps chugging. UT1 instead varies the length of the second so each day contains the same number of seconds. The variance would be less than 12ppm (1mil/seconds in a day), but some applications like navigation would have issues.

EDIT: Most computers end up using a modified version of UTC where the leap second is smeared at the NTP level instead of explicitly experienced. So any computer that uses that could probably use UT1. But we couldn't use UT1 universally.

If you set your clock to UT1 then it will be “wrong” by up to 0.9 seconds fast or slow compared to UTC, and the length of your seconds will be “wrong” by up to about 1e-8 compared to SI seconds. (Before its recent speed-up, the earth took about 24x60x60+0.001 seconds to rotate.)

One of the key reasons for moving away from UT1 or UT2 as the standard broadcast timescales up to 1972 was that the time broadcasts were (and are still) also frequency broadcasts, so when they adjusted the length of the second to match the earth, they also had to retune their high-power transmitter so that the advertised number of cycles per second was correct. And when this retuning happened they also had to promulgate the new adjustment factor to all their users who needed actual SI or ephemeris time seconds instead of rubber UT1 seconds.

ntpdate shows ~120ms difference from UTC, though from the docs it looks like there is a table to calculate the exact difference.

Reply on news.ycombinator.com