- A instalação de tempo do NIST em Boulder, Colorado, nos EUA, ficou vários dias fora de operação por causa de um apagão e, após a falha de um gerador de backup, ocorreu um erro de até 5 μs em relação ao padrão UTC
- A instalação, que opera 6 servidores NTP, conseguiu manter o desvio de tempo abaixo de 5 μs apesar da falha do gerador, com impacto quase nulo para usuários comuns
- Pode ter havido impacto para instituições de pesquisa científica e empresas aeroespaciais que dependem de temporização precisa, e o NIST está trabalhando diretamente com elas
- Os sistemas GPS e WWV-Ft. Collins funcionaram normalmente como backup, comprovando a redundância da infraestrutura de tempo dos EUA
- O caso mostra os riscos da dependência do GPS e a fragilidade da infraestrutura de temporização, destacando a necessidade de desenvolver sistemas PNT alternativos
Apagão e surgimento do erro de tempo
- O campus do NIST em Boulder, Colorado, foi afetado por ventos acima de 160 km/h (100 mph), e a concessionária interrompeu o fornecimento de energia para evitar risco de incêndio
- Todo o campus foi isolado, impedindo a entrada de funcionários e atrasando a recuperação
- Um dos geradores de backup falhou dois dias depois, cortando a energia do principal conjunto de relógios (
clock ensemble) dos servidores NTP
- Jeff Sherman, chefe do Time Realization and Distribution Group, chegou a considerar desligar os servidores para evitar a distribuição de um horário incorreto
- Felizmente, o sistema de relógios de outro prédio conseguiu transmitir o sinal de tempo, e alguns funcionários permaneceram no local para restabelecer o serviço com redirecionamento emergencial de energia
- O backup por bateria (UPS) manteve o tempo até a troca do gerador e, no fim, o desvio em relação ao UTC ficou abaixo de 5 μs
Operação dos servidores NTP e alcance do impacto
- O NIST fornece serviço de horário na internet por meio de 6 servidores NTP principais
- No resultado do comando
sntp time-a-b.nist.gov, o erro causado pela latência de rede para usuários comuns é de cerca de 35 milissegundos (35.000 μs), então um erro de 5 μs é desprezível
- Por isso, os servidores permaneceram ativos e a precisão ficou cerca de 5.000 vezes pior que o normal, mas sem impacto para a maioria dos usuários
- Universidades, setor aeroespacial e instituições de pesquisa científica podem ser sensíveis até a pequenas variações, então o NIST está trabalhando diretamente com esses grupos para correção
- O sistema GPS dos EUA alternou automaticamente para o campus WWV-Ft. Collins, mantendo todo o serviço sem interrupção total
Fragilidade da infraestrutura de tempo e tecnologias alternativas
- O autor opera seu próprio servidor NTP usando dois relógios GPS baseados em Raspberry Pi e aponta os riscos da dependência do GPS
- A CISA já alertou para o risco de dependência excessiva do GPS nos EUA, e o governo vem promovendo o desenvolvimento de tecnologias PNT (Position, Navigation, Timing) alternativas
- O Broadcast Positioning System (BPS) está sendo discutido como candidato para substituir o GPS
- O autor usa um relógio atômico de rubídio e GPSDO para manter precisão de alguns nanossegundos, sendo possível manter o tempo por meses mesmo com falha no sinal de GPS
- No entanto, áreas como ciência, RF, mídia e finanças exigem precisão na casa dos nanossegundos, e a maioria faz referência ao padrão de tempo do NIST
Lições e confiabilidade do sistema
- O incidente comprovou que o sistema de resposta a desastres do NIST realmente funcionou, mostrando uma operação normal mesmo com um pequeno erro
- A combinação de energia redundante, múltiplos relógios e backup por GPS manteve a estabilidade da infraestrutura nacional de tempo
- O autor enfatiza que a infraestrutura de temporização é muito frágil e exige múltiplos backups
- Mesmo em uma situação crítica na escala de microssegundos, a equipe do NIST resolveu o problema e concluiu a recuperação sem que a maioria dos usuários percebesse
1 comentários
Comentários do Hacker News
O programa Time Over Fiber (TOF) do NIST foi o que achei mais interessante
Esse serviço fornece distribuição de tempo de alta precisão por fibra óptica, e parece que alguns links conectados diretamente foram afetados
Nunca tinha ouvido falar desse tipo de serviço, mas imagino que possa ser usado em finanças (HFT, relacionado à regra 4590 da FINRA), sincronização de 5G ou para bancos de dados globais como o Google Spanner
Links relacionados: aviso do NIST, explicação do programa TOF, FINRA Rule 4590, artigo sobre sincronização em 5G
Em sistemas de trading em tempo real, GPS já era suficiente, e latência importava mais do que precisão na escala de microssegundos
Os requisitos regulatórios também permitem erro de 1 segundo, então a precisão do TOF não é exigida
Por exemplo, quando é preciso sincronizar com precisão dados de áreas amplas, como em observações simultâneas de ondas gravitacionais e explosões de raios gama
Por exemplo, lugares como a Schriever Space Force Base são pontos principais de controle do GPS
Também é importante como uma rede terrestre de tempo para contingência quando sinais de GNSS caem
Artigo relacionado: sistema terrestre chinês de temporização de alta precisão
Na prática, só os servidores de Boulder tiveram problema de sincronização
Dizer que “o NIST inteiro ficou offline” é exagero
Segundo a página de status dos servidores, apenas 5 dos 16 servidores NTP IPv4 foram afetados, e os demais continuaram funcionando normalmente
A maioria dos usuários nem deveria usar diretamente os servidores de topo, então o impacto foi mínimo
Pessoalmente, recomendo usar o pool.ntp.org
Será que existe risco de propagação do erro? O pool.ntp.org é distribuído de forma a evitar correlação entre falhas ou desvios?
Pequena correção: UTC é a sigla de “Coordinated Universal Time”
A ordem das letras foi ajustada para não favorecer nem o inglês nem o francês
Também houve preocupação em manter consistência com o sistema anterior de abreviações, como UT0, UT1 e UT2
Fugindo um pouco do tema, queria elogiar o chrony
Em vários tipos de hardware, ele foi muito mais estável que o cliente NTP padrão do sistema operacional
Isso por si só mostra que desempenho e estabilidade já foram comprovados
Esta thread está interessante demais, não consigo parar de ler
Talvez seja porque tomei Adderall demais hoje
Ouvi dizer que alguns traders de HFT ganharam centenas de milhares de dólares com esse incidente
Queria saber se foi exploração deliberada do sistema ou só um glitch em que deram sorte
Antigamente se dizia que “transmitir a hora errada é pior do que não transmitir nada”, então não entendo por que desta vez eles enviaram um horário com erro
Segundo a lista de e-mails do NIST, na internet normalmente há incerteza na casa de 1ms, então está em outra escala de precisão em relação ao uso científico
Naquele momento, tanto a energia quanto o acesso administrativo tinham sido perdidos, então não havia como saber o quanto os relógios estavam errados
Se um horário incorreto tivesse sido propagado assim que a energia voltasse, sistemas no mundo inteiro poderiam entrar em erro de sincronização
Por isso era melhor fazer um desligamento de segurança (scram)
Conto relacionado: The Time Rift of 2100
Por exemplo, é mais seguro um alarme de incêndio não responder do que informar incorretamente que “está tudo bem”
Não entendi o título do vídeo dizendo que “o relógio do NIST esteve à beira do desastre”
Não bastaria corrigir a hora a partir de outro campus?
Se realmente existe algum caso que exija esse nível de precisão, seria bom ouvir uma explicação de especialista
Fiquei curioso sobre quais foram os casos mais importantes em que as pessoas precisaram de tempo preciso
Usamos White Rabbit para sincronizar sistemas de potência de RF e equipamentos de aquisição de dados na escala de nanossegundos
Com o TrueTime, ele garante consistência transacional global
Se um satélite GPS errasse por esse tanto, a precisão de posicionamento cairia para algo no nível do Loran-C
A história começou por causa de uma matéria da NPR
link original