Live data from Hacker News

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

jeffgeerling.com

101–110 of 162 posts

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

#101
post #50

Nitpick: UTC stands for Coordinated Universal Time. The ordering of the letters was chosen to not match the English or the French names so neither language got preference.

Universal Time, Coordinated.

This is how I say it in my head.

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

#102
post #51

I found the most interesting part of the NIST outage post [1] is NIST's special Time Over Fiber (TOF) program [2] that "provides high-precision time transfer by other service arrangements; some direct fiber-optic links were affected and users will be contacted separately." I've never heard of this! Very cool service, presumably for … quant / HFT / finance firms (maybe for compliance with FINRA Rule 4590 [3])? Telecom…

I think Google uses chrony instead of NTP

Google doesn't use chrony specifically, just an algorithm that is somewhat chrony-like (but very different in other ways). It's called Google TrueTime.

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

#103

Earlier quoted context omitted.

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

GPS gets its time from NIST (though during this incident they failed over to another NIST site, so it wasn't impacted).

That is not correct at all. How did you arrive at that conclusion?

GPS has its own independent timescale called GPS Time. GPS Time is generated and maintained by Atomic clocks onboard the GPS satellites (cesium and rubidium).

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

#104
post #64

Only Boulder servers lost sync. To say NIST was off is clickbait hyperbole. This page: https://tf.nist.gov/tf-cgi/servers.cgi shows that NIST has > 16 NTP servers on IPv4, of those, 5 are in Boulder and were affected by the power failure. The rest were fine. However, most entities should not be using these top-level servers anyway, so this should have been a problem for exactly nobody. IMHO, most applications should…

I believe if you use time.nist.gov it round robins dns requests, so there’s a chance you’d have connected to the Boulder server. So for some people they would have experienced NIST 5 μs off.

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

#105

Earlier quoted context omitted.

GPS gets its time from NIST (though during this incident they failed over to another NIST site, so it wasn't impacted).

That is not correct at all. How did you arrive at that conclusion? GPS has its own independent timescale called GPS Time. GPS Time is generated and maintained by Atomic clocks onboard the GPS satellites (cesium and rubidium).

I think GP might’ve been referring to the part of Jeff’s post that references GPS, which I think may be a slight misunderstanding of the NIST email (saying “people using NIST + GPS for time transfer failed over to other sites” rather than “GPS failed over to another site”).

The GPS satellite clocks are steered to the US Naval Observatory’s UTC as opposed to NIST’s, and GPS fails over to the USNO’s Alternate Master Clock [0] in Colorado.

[0] https://www.cnmoc.usff.navy.mil/Our-Commands/United-States-N...

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

#106
post #20
post #10

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

We don't use NTP, but for robotics, stereo camera synchronization we often want the two frames to be within ~10us of eachother. For sensor fusion we then also need a lidar on PTP time to be translated to the same clock domain as cameras, for which we also need We actually disable NTP entirely (run it once per day or at boot) to avoid clocks jumping while recording data.

For a low precision environment to avoid sudden jumps I used SetSystemTimeAdjustment on Windows (now SetSystemTimeAdjustmentPrecise) to smoothly steer the system clock to match the GPS supplied time signal.

On Linux I think the adjtimex() system call does the equivalent https://manpages.ubuntu.com/manpages/trusty/man2/adjtimex.2....

It smears out time differences which is great for some situations and less ideal for others.

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

#107
post #94

Earlier quoted context omitted.

My guess would be scientific experiments where they need to correlate or sequence data over large regions. Things like correlating gravitational waves with radio signals and gamma ray bursts.

those are GPS based too. You typically would have a circuit you trained off off 1PPS and hopefully had a 10 or so satellites in view. You can get 50ns with this. Of course, you would verify at NIST.

GPS could be blocked easily, and AFAIK even given corrupted inputs. And HFT could possibly benefit from blocking or corrupting competitors GPS.

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

#108
post #64

Only Boulder servers lost sync. To say NIST was off is clickbait hyperbole. This page: https://tf.nist.gov/tf-cgi/servers.cgi shows that NIST has > 16 NTP servers on IPv4, of those, 5 are in Boulder and were affected by the power failure. The rest were fine. However, most entities should not be using these top-level servers anyway, so this should have been a problem for exactly nobody. IMHO, most applications should…

Who does use those top-level servers? Aren’t some of them propagating the error or are all secondary level servers configured to use dispersed top-level servers? And how do they decide who is right when they don’t match? Is pool.ntp.org dispersed across possible interference and error correlation?

From my own experience managing large numbers of routers, and troubleshooting issues, I will never use pool.ntp.org again. I’ve seen unresponsive servers as well as incorrect time by hours or days. It’s pure luck to get a good result.

Instead I’ll stick to a major operator like Google/Microsoft/Apple, which have NTP systems designed to handle the scale of all the devices they sell, and are well maintained.

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

#109
post #50

Nitpick: UTC stands for Coordinated Universal Time. The ordering of the letters was chosen to not match the English or the French names so neither language got preference.

That's an interesting rationale.

Reminds me of when a group is divided into two parts, dubbed group 1 and group A, such that neither feels secondary.
Post reply on HN