Are there any plans being made to prevent this happening in the future?
Yes, the US government is banning all those democrat windmills that conspired to blow over the NTP server.
[deleted]
NIST was 5 μs off UTC after last week's power cut
61–70 of 162 posts
Re: NIST was 5 μs off UTC after last week's power cut
#62I 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…
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.
Re: NIST was 5 μs off UTC after last week's power cut
#63Has anyone here ever needed microsecond precision? Would love to hear about it.
Lightning detection. You have a couple of ground stations with known positions that wait for certain electromagnetic puses, and which record the timestamps of such pulses. With enough stations you can triangulate the location of the source of each pulse. Also a great way to detect nuclear detonations.
There is a german club that builds and distrubutes such stations (using GPS for location and timing), with a quite impressive global coverage by now:
Re: NIST was 5 μs off UTC after last week's power cut
#64Only 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 use pool.ntp.org
Re: NIST was 5 μs off UTC after last week's power cut
#65I 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…
SIGINT as a source clock for others in a network doing super accurate TDOA for example.
Re: NIST was 5 μs off UTC after last week's power cut
#66Has anyone here ever needed microsecond precision? Would love to hear about it.
Nuclear measurements, where the speed of a gamma ray flying across a room vs a neutron is relevant. But that requires at least nanosecond time resolution, and you’re a long way from thinking about NTP.
Re: NIST was 5 μs off UTC after last week's power cut
#67Earlier quoted context omitted.
I never saw a need for this in HFT. In my experience, GPS was used instead, but there was never any critical need for microsecond accuracy in live systems. Sub-microsecond latency, yes, but when that mattered it was in order to do something as soon as possible rather than as close as possible to Wall Clock Time X. Still useful for post-trade analysis; perhaps you can determine that a competitor now has a faster conne…
> I never saw a need for this in HFT. In my experience, GPS was used instead, but there was never any critical need for microsecond accuracy in live systems. mifid ii (uk/eu) minimum is 1us granularity https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:...
It's 1 us granularity, which means you should report your timestamps with six figures after the decimal point.
The required accuracy (Tables 1 and 2 in that document) is 100 us or 1000 us depending on the system.
Re: NIST was 5 μs off UTC after last week's power cut
#68Earlier quoted context omitted.
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.
> We actually disable NTP entirely (run it once per day or at boot) to avoid clocks jumping while recording data. This doesn't seem right to me. NTP with default settings should be monotonic. So no jumps. If you disable it Linux enters 11-minute mode, IIRC, and that may not be monotonic.
Pedantically, a monotonic function need not have a constant first derivative. To take it further, in mathematics it is accepted for a monatomic function to have a countable number of discontinuities, but of course in the context of a digital clock that only increments in discrete steps, that’s of little bearing.
But that’s all besides the point since most sane time sync clients (regardless of protocol) generally handle small deviations (i.e. normal cases) by speeding up or slowing down the system clock, not jumping it (forward or backward).
Re: NIST was 5 μs off UTC after last week's power cut
#69Not exactly the topic of discussion but also not not on topic: just wanted to sing praise for chrony which has performed better than the traditional os-native NTP clients in our testing on a myriad of real and virtualized hardware.
Re: NIST was 5 μs off UTC after last week's power cut
#70I 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…
> a commercial consumer
Where does it say these are commercial consumers?
https://en.wikipedia.org/wiki/Schriever_Space_Force_Base#Rol...
> Building 400 at Schriever SFB is the main control point for the Global Positioning System (GPS).