I'm missing the nuance or perhaps the difference between the first scenario where sending inaccurate time was worse than sending no time, versus the present where they are sending inaccurate time. Sorry if it's obvious.

▲

opello 9 hours ago | parent | next [-]

The 5us inaccuracy is basically irrelevant to NTP users, from the second update to the Internet Time Service mailing list[1]:

To put a deviation of a few microseconds in context, the NIST time scale usually performs about five thousand times better than this at the nanosecond scale by composing a special statistical average of many clocks. Such precision is important for scientific applications, telecommunications, critical infrastructure, and integrity monitoring of positioning systems. But this precision is not achievable with time transfer over the public Internet; uncertainties on the order of 1 millisecond (one thousandth of one second) are more typical due to asymmetry and fluctuations in packet delay.

[1] https://groups.google.com/a/list.nist.gov/g/internet-time-se...

▲

zahlman 8 hours ago | parent [-]

> Such precision is important for scientific applications, telecommunications, critical infrastructure, and integrity monitoring of positioning systems. But this precision is not achievable with time transfer over the public Internet

How do those other applications obtain the precise value they need without encountering the Internet issue?

▲

throw0101d 7 hours ago | parent | next [-]

> How do those other applications obtain the precise value they need without encountering the Internet issue?

They do not use the Internet: they use local (GPS) clocks with internal high-precision clocks for carry-over in case GNSS signal is unavailable:

* https://www.ntp.org/support/vendorlinks/

* https://www.meinbergglobal.com/english/products/ntp-time-ser...

* https://syncworks.com/shop/syncserver-s650-rubidium-090-1520...

* https://telnetnetworks.ca/solutions/precision-time/

▲

herpderperator 6 hours ago | parent | next [-]

If those other applications use their own local GPS clocks, what is the significance of NIST (and the 5μs inaccuracy) in their scenario?

	▲	throw0101c an hour ago \| parent \| next [-]
		> If those other applications use their own local GPS clocks, what is the significance of NIST (and the 5μs inaccuracy) in their scenario? Verification and traceability is one reason: it's all very well to claim you're with-in ±x seconds, but your logs may have to say how close you are to the 'legal reality' that is the official time of NIST. NIST may also send out time via 'private fibre' for certain purposes: * https://en.wikipedia.org/wiki/White_Rabbit_Project 'Fibre timing' is also important in case of GNSS signal disruption: * https://www.gpsworld.com/china-finishing-high-precision-grou...
	▲	Denvercoder9 3 hours ago \| parent \| prev [-]
		GPS gets its time from NIST (though during this incident they failed over to another NIST site, so it wasn't impacted).

▲

lysace 7 hours ago | parent | prev [-]

TIL/remembered GNSS satellites have onboard atomic clocks. Makes a lot of sense, but still pretty cool. Something like this, I guess?

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

	▲	CamperBob2 7 hours ago \| parent [-]
		Yes, either Rb, Cs, or H standards depending on which GNSS system you're using. For the most critical applications, you can license a system like Fugro AtomiChron that provides enhanced GNSS timing down to the level of a few nanoseconds. There are a couple of products that do similar things, all based on providing better ephemerides than your receiver can obtain from the satellites themselves. You can get AtomiChron as an optional subscription with the SparkPNT GPSDO, for instance (https://www.sparkfun.com/sparkpnt-gnss-disciplined-oscillato...).

▲

geerlingguy 7 hours ago | parent | prev | next [-]

A lot of organizations also colocate timing equipment near the actual clocks, and then have 'dark fiber' between their equipment and the main clock signals.

Then they disperse and use the time as needed.

According to jrronimo, they even had one place splice fiber direct between machines because couplers were causing problems! [1]

[1] https://news.ycombinator.com/item?id=46336755

	▲	vasco 7 hours ago \| parent [-]
		If I put my machine near the main clock signal, I have one clock signal to read from. The comment above was asking about how to average across many different clocks, presumably all in different places in the globe? Unless there's one physical location with all of the ones you're averaging, you're close to one and far from all the others so how is it done without the internet?

▲

LeoPanthera 8 hours ago | parent | prev [-]

If you must use the internet, PTP gets closer.

Alternate sources include the GPS signal, and the WWVB radio signal, which has a 60kHz carrier wave accurate to less than 1 part in 10^12.

	▲	aftbit 7 hours ago \| parent [-]
		Can you do PTP over the internet? I have only seen it in internal environments. GPS is probably the best solution for external users to get time signals with sub-µs uncertainties.

▲

BuildTheRobots 9 hours ago | parent | prev | next [-]

It's a good question, and I wondered the same. I don't know, but I'd postulate:

As it stands at the minute, the clocks are a mere 5 microseconds out and will slowly get better over time. This isn't even in the error measurement range and so they know it's not going to have a major effect on anything.

When the event started and they lost power and access to the site, they also lost their management access to the clocks as well. At this point they don't know how wrong the clocks are, or how more wrong they're going to get.

If someone restores power to the campus, the clocks are going to be online (all the switches and routers connecting them to the internet suddenly boot up), before they've had a chance to get admin control back. If something happened when they were offline and the clocks drifted significantly, then when they came online half the world might decide to believe them and suddenly step change to follow them. This could cause absolute havoc.

Potentially safer to scram something than have it come back online in an unknown state, especially if (lots of) other things are are going to react to it.

In the last NIST post, someone linked to The Time Rift of 2100: How We lost the Future --- and Gained the Past. It's a short story that highlights some of the dangers of fractured time in a world that uses high precision timing to let things talk to each other: https://tech.slashdot.org/comments.pl?sid=7132077&cid=493082...

▲

throw0101d 7 hours ago | parent | prev [-]

> […] where sending inaccurate time was worse than sending no time […]

When you ask a question, it is sometimes better to not get an answer—and know you have not-gotten an answer—then to get the wrong answer. If you know that a 'bad' situation has arisen, you can start contingency measures to deal with it.

If you have a fire alarm: would you rather have it fail in such a way that it gives no answer, or fail in a way where it says "things are okay" even if it doesn't know?