Atomic time source failure at NIST Gaithersburg campus
groups.google.com
Atomic time source failure at NIST Gaithersburg campus
1–10 of 11 posts
Re: Atomic time source failure at NIST Gaithersburg campus
#2Huh, I guess it's best to think of each site's NIST NTP servers as 'load-balancers' in front of a single 'application server'.
Fun fact: Per [0], if you provide enough servers, the NTP client can detect a "falseticker" that is not providing accurate time. The number of NTP servers required is `2n+1` where `n≥1`.
Of course, that requires each NTP server use its own time source.
So, note for me: If I want NTP redundancy and I'm using NIST's servers, pick one NTP server from each of NTP's three sites.
[0]: https://support.ntp.org/Support/SelectingOffsiteNTPServers#U...
Re: Atomic time source failure at NIST Gaithersburg campus
#3I wonder if it’s a response to this https://www.reuters.com/world/china/china-accuses-us-cyber-b...
Re: Atomic time source failure at NIST Gaithersburg campus
#4Huh, I guess it's best to think of each site's NIST NTP servers as 'load-balancers' in front of a single 'application server'. Fun fact: Per [0], if you provide enough servers, the NTP client can detect a "falseticker" that is not providing accurate time. The number of NTP servers required is `2n+1` where `n≥1`. Of course, that requires each NTP server use its own time source. So, note for me: If I want NTP redundanc…
-10ms, no redundant clocks, and they're leaving most of the servers up with that amount of skew. Wow. I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures.
Re: Atomic time source failure at NIST Gaithersburg campus
#5Good to know they have multiple backup clocks across the continental US.
Re: Atomic time source failure at NIST Gaithersburg campus
#6Huh, I guess it's best to think of each site's NIST NTP servers as 'load-balancers' in front of a single 'application server'. Fun fact: Per [0], if you provide enough servers, the NTP client can detect a "falseticker" that is not providing accurate time. The number of NTP servers required is `2n+1` where `n≥1`. Of course, that requires each NTP server use its own time source. So, note for me: If I want NTP redundanc…
-10ms, no redundant clocks, and they're leaving most of the servers up with that amount of skew. Wow. I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures.
They do have multiple clocks and sites. The primary clock is in Boulder. Only the Maryland time servers are affected, the Colorado ones should be fine. They mention switching to another atomic clock, but that probably has to be setup.
The email explains why they haven't shut down, cause haven't hit the threshold. And talks about maybe shutting them down manually.
Re: Atomic time source failure at NIST Gaithersburg campus
#7Huh, I guess it's best to think of each site's NIST NTP servers as 'load-balancers' in front of a single 'application server'. Fun fact: Per [0], if you provide enough servers, the NTP client can detect a "falseticker" that is not providing accurate time. The number of NTP servers required is `2n+1` where `n≥1`. Of course, that requires each NTP server use its own time source. So, note for me: If I want NTP redundanc…
-10ms, no redundant clocks, and they're leaving most of the servers up with that amount of skew. Wow. I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures.
> I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures.
They may not operate redundant clocks at a single site, but ITS redundancy posture[1] doesn't look bad at all:
>> Servers at the Boulder and WWV/Ft. Collins campuses are independent and unaffected.
Re: Atomic time source failure at NIST Gaithersburg campus
#8Huh, I guess it's best to think of each site's NIST NTP servers as 'load-balancers' in front of a single 'application server'. Fun fact: Per [0], if you provide enough servers, the NTP client can detect a "falseticker" that is not providing accurate time. The number of NTP servers required is `2n+1` where `n≥1`. Of course, that requires each NTP server use its own time source. So, note for me: If I want NTP redundanc…
-10ms, no redundant clocks, and they're leaving most of the servers up with that amount of skew. Wow. I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures.
> I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures.
Is this sarcasm? I can't tell.
Per the email:
> Servers at the Boulder and WWV/Ft. Collins campuses are independent and unaffected.
Re: Atomic time source failure at NIST Gaithersburg campus
#9Huh, I guess it's best to think of each site's NIST NTP servers as 'load-balancers' in front of a single 'application server'. Fun fact: Per [0], if you provide enough servers, the NTP client can detect a "falseticker" that is not providing accurate time. The number of NTP servers required is `2n+1` where `n≥1`. Of course, that requires each NTP server use its own time source. So, note for me: If I want NTP redundanc…
> So, note for me: If I want NTP redundancy and I'm using NIST's servers, pick one NTP server from each of NTP's three sites.
System robustness hazard that won't tolerate just querying time.nist.gov at 4-sec or greater intervals?
From the cow's mouth[1]:
>> The global address time.nist.gov is resolved to all of the server addresses below in a round-robin sequence to equalize the load across all of the servers.
Re: Atomic time source failure at NIST Gaithersburg campus
#10Earlier quoted context omitted.
-10ms, no redundant clocks, and they're leaving most of the servers up with that amount of skew. Wow. I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures.
> I am astonished that NIST does not have multiple clocks over multiple distributed sites with robust ability to detect and bypass individual failures. Is this sarcasm? I can't tell. Per the email: > Servers at the Boulder and WWV/Ft. Collins campuses are independent and unaffected.
Sorry, maybe I got carried away with the tone. But it is not sarcasm. I genuinely did not realise that the NTP service level was so low. There are two problems raised in the email: There is no on-site redundant fail-over upstream of the NTP servers. All NTP servers at the site were not automatically taken down immediately upon detection of the fault (because some were still, in some sense, within tolerance). This places all of the fault management onto downstream NTP servers. I honestly expected NIST to be running a robust cross-site timebase upstream of NTP.