Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NIST was 5 μs off UTC after last week's power cut

jeffgeerling.com

Post reply on HN
Print view View original

31–40 of 162 posts

Re: NIST was 5 μs off UTC after last week's power cut

#31

Post by aftbit »

LeoPanthera wrote: post #29
zahlman wrote: post #28

Earlier quoted context omitted.

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

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.

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.

Re: NIST was 5 μs off UTC after last week's power cut

#33

Post by throw0101d »

politelemon wrote: post #8

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.

> […] 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?

Re: NIST was 5 μs off UTC after last week's power cut

#34

Post by bobmcnamara »

V__ wrote: post #10

Has anyone here ever needed microsecond precision? Would love to hear about it.

Yes, but always got it from GPS so presumably they'd be off about the same amount.

Distributed sonar, allows placing receivers willy-nilly and aligning the samples later.

Remote microphone switching - though for this you wouldn't notice 5us jitter, it's just that the system we designed happened to have granularity that good.

Re: NIST was 5 μs off UTC after last week's power cut

#35

Post by throw0101d »

zahlman wrote: post #28
opello wrote: post #15

Earlier quoted context omitted.

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, c…

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

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

Re: NIST was 5 μs off UTC after last week's power cut

#36

Post by geerlingguy »

zahlman wrote: post #28
opello wrote: post #15

Earlier quoted context omitted.

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, c…

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

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

Re: NIST was 5 μs off UTC after last week's power cut

#37

Post by lysace »

throw0101d wrote: post #35
zahlman wrote: post #28

Earlier quoted context omitted.

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

> 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-09…

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

Re: NIST was 5 μs off UTC after last week's power cut

#38

Post by vasco »

geerlingguy wrote: post #36
zahlman wrote: post #28

Earlier quoted context omitted.

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

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

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?

Re: NIST was 5 μs off UTC after last week's power cut

#39

Post by pi-rat »

V__ wrote: post #10

Has anyone here ever needed microsecond precision? Would love to hear about it.

High speed finance is msec and below. Fastest publically known tick to trade is just shy of 14 nanos.

Timekeeping starts to become really hard, often requiring specialized hardware and protocols.

Re: NIST was 5 μs off UTC after last week's power cut

#40

Post by Aromasin »

V__ wrote: post #10

Has anyone here ever needed microsecond precision? Would love to hear about it.

I worked at Altera (FPGA supplier) as the Ethernet IP apps engineer for Europe for a few years. All the big telecoms (Nokia, Ericsson, Cisco, etc) use Precision Time Protocol (PTP) in some capacity and all required clocks to be ns levels for accuracy. Sometimes as low a 10ns at the boundary. Any imperfection in the local clock directly converts into timestamp error, and timestamp error is what limits PTP synchronization performance. Timestamps are the fundamental observable in PTP. Quantization and jitter create irreducible timestamp noise. That noise directly limits offset and delay estimation. Errors accumulate across network elements and internal clock error must be much smaller than the system requirement.

I think most people would look at the error and think "what's the big deal" but at all the telecoms customers would be scrambling to find a clock that hasn't fallen out of sync.

Post reply on HN