4 ms·
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 whe
by politelemon 10mo ago
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.
- BuildTheRobots 10mo agoIt'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=49308245 https://tech.slashdot.org/comments.pl?sid=7132077&cid=493082...
- opello 10mo agoThe 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-service/c/OHOO_1OYjLY https://groups.google.com/a/list.nist.gov/g/internet-time-se...
- zahlman 10mo ago> 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?
- LeoPanthera 10mo agoIf 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 10mo agoCan 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.
- throw0101d 10mo ago> 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.ntp.org/support/vendorlinks/ * https://www.meinbergglobal.com/english/products/ntp-time-server.htm https://www.meinbergglobal.com/english/products/ntp-time-ser... * https://syncworks.com/shop/syncserver-s650-rubidium-090-15200-652/ https://syncworks.com/shop/syncserver-s650-rubidium-090-1520... * https://telnetnetworks.ca/solutions/precision-time/ https://telnetnetworks.ca/solutions/precision-time/
- lysace 10mo agoTIL/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 https://en.wikipedia.org/wiki/Rubidium_standard
- throw0101d 10mo ago> […] 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?