Abrir o código-fonte de um dispositivo de tempo mais preciso

Os engenheiros do Facebook criaram e disponibilizaram um dispositivo de tempo de computação aberto, um componente importante da infraestrutura de temporização moderna. Para tornar isso possível, criamos o cartão de ponto - um cartão PCI Express (PCIe) que pode transformar quase qualquer servidor comum em um dispositivo de tempo. Com a ajuda da comunidade OCP, estabelecemos o Open Compute Time Appliance Project e disponibilizamos o código-fonte de todos os aspectos do Open Time Server. Este artigo descreve o desenvolvimento do cartão de ponto.

Em março de 2020, anunciamos que estávamos em processo de troca dos servidores em nossos data centers (junto com nossos produtos de consumo) para um novo serviço de cronometragem baseado no Network Time Protocol (NTP). O novo serviço, criado internamente e posteriormente com código-fonte aberto, era mais escalonável e melhorou a precisão da cronometragem na infraestrutura do Facebook de 10 milissegundos para 100 microssegundos. Uma manutenção de tempo mais precisa permite um gerenciamento de infraestrutura mais avançado em nossos data centers, bem como um desempenho mais rápido de bancos de dados distribuídos.

A nova arquitetura de tempo baseada em NTP usa um Stratum 1 - um componente importante que está diretamente vinculado a uma fonte oficial de tempo, como um Sistema Global de Navegação por Satélite (GNSS) ou um relógio de césio, conforme mostrado abaixo:

Muitas empresas contam com pools públicos de NTP, como time.facebook.com, para atuar como seu Stratum 1. No entanto, essa abordagem tem suas desvantagens. Esses pools adicionam dependência à conectividade com a Internet e podem afetar a segurança geral e a confiabilidade do sistema. Por exemplo, se a conectividade for perdida ou um serviço externo estiver inativo, isso pode resultar em interrupções ou desvios no tempo do sistema dependente.

Para remover essas dependências, construímos uma nova peça de hardware dedicada chamada de dispositivo de tempo, que consiste em um receptor GNSS e um relógio atômico miniaturizado (MAC). Os usuários de aparelhos de tempo podem manter a hora precisa, mesmo no caso de perda de conectividade GNSS. Ao construir nosso dispositivo de tempo, também inventamos um cartão de tempo, um cartão PCIe que pode transformar qualquer servidor comum em um dispositivo de tempo.

Por que a necessidade de um novo dispositivo de hora?

Os aparelhos com tempo de uso padrão têm seus próprios benefícios. Eles funcionam direto da caixa e, como muitos desses dispositivos estão no mercado há décadas, eles são testados em batalha e geralmente estáveis ​​o suficiente para funcionar sem supervisão por um longo tempo.

No entanto, essas soluções também apresentam vantagens e desvantagens:

• Na maioria dos casos, eles estão desatualizados e frequentemente vulneráveis ​​a questões de segurança de software. Solicitações de recursos e correções de segurança podem levar meses ou até anos para serem implementadas.
• Esses dispositivos vêm com software de código fechado, o que torna a configuração e o monitoramento deles limitados e desafiadores. Embora a configuração seja feita manualmente por meio de uma CLI proprietária ou IU da web, o monitoramento geralmente usa SNMP, um protocolo que não foi projetado para essa finalidade.
• Eles incluem hardware proprietário que não pode ser reparado pelo usuário. Quando um único componente quebra, não há maneira fácil de substituí-lo. Você deve enviá-lo ao fornecedor para conserto ou comprar um aparelho novo inteiro.
• Como os dispositivos de prateleira são feitos em pequenas quantidades, eles vêm com uma marcação mais alta e podem se tornar muito caros para operar com o tempo. O alto custo associado aos dispositivos prontos para uso cria limitações para muitos na indústria. Uma versão de código aberto abriria a porta para aplicativos mais amplos.

Até agora, as empresas tiveram que aceitar essas compensações e trabalhar dentro das restrições descritas acima. Decidimos que era hora de tentar algo diferente, então analisamos seriamente o que seria necessário para construir um novo dispositivo de tempo - especificamente, um usando a arquitetura x86.

Prototipar o aparelho do tempo

Aqui está um diagrama de blocos do que imaginamos:

Tudo começa a partir de um receptor GNSS que fornece a hora do dia (ToD), bem como um pulso por segundo (PPS). Quando o receptor é apoiado por um oscilador de alta estabilidade (por exemplo, um relógio atômico ou um oscilador de cristal controlado por forno), ele pode fornecer um tempo com precisão de nanossegundos. A hora é entregue pela rede por meio de uma placa de rede pronta para uso que suporta entrada / saída PPS e marcação de tempo de hardware de pacotes, como o NVIDIA Mellanox ConnectX-6 Dx usado em nosso dispositivo inicial.

A saída do GPSDO foi alimentada na marcação de tempo EXT da placa de rede ConnectX-6 Dx. Além disso, o receptor GNSS fornece o ToD por meio de uma porta serial e um protocolo de relatório GPS popular chamado NMEA. O uso da ferramenta ts2phc nos permitiu sincronizar o relógio físico do hardware da NIC em algumas dezenas de nanossegundos, conforme mostrado abaixo:

Nosso protótipo nos deu a confiança de que construir tal aparelho era possível. No entanto, havia muito espaço para melhorias.

Para aumentar a confiabilidade do sistema, nós o dividimos em duas partes principais:carga útil e entrega. A carga útil é o tempo de precisão que é essencialmente um sistema de interpolação conduzido por um oscilador local para criar nanossegundos de medição de tempo entre sinais PPS consecutivos recebidos pelo receptor GNSS. Consideramos colocar o receptor GNSS, o oscilador local de alta estabilidade e a lógica de processamento necessária em um fator de forma PCIe e o chamamos de cartão de tempo (veja abaixo).

Aqui está o esboço do cartão de ponto que inicialmente imaginamos em um guardanapo:

Usamos um MAC integrado, um receptor GNSS multibanda e um FPGA para implementar o mecanismo de tempo. O trabalho do mecanismo de tempo é interpolar em nanossegundos a granularidade necessária entre os sinais PPS consecutivos. O receptor GNSS também fornece um ToD além de um sinal 1 PPS. No caso de perda de recepção GNSS, o mecanismo de tempo depende da sincronização contínua do relógio atômico com base em um conjunto médio de pulsos PPS consecutivos.

O mecanismo de tempo consiste em um conjunto de blocos de processamento implementados no FPGA do cartão de tempo. Esses blocos de processamento incluem vários filtros, sincronização, verificação de erros, registro de data e hora e subsistemas relacionados a PCIe para permitir que o cartão de tempo funcione como um periférico do sistema que fornece tempo de precisão para o servidor de tempo aberto.

Deve-se notar que a precisão de um receptor GNSS está dentro de dezenas de nanossegundos, enquanto a sincronização contínua necessária (calibração) do MAC está dentro de 10 picossegundos (1.000 vezes mais preciso).

À primeira vista, isso parece impossível. No entanto, o sistema GNSS fornece temporização com base na comunicação contínua com a hora padrão. Essa capacidade permite que o relógio integrado GNSS seja constantemente sincronizado com uma fonte de tempo fornecida à sua constelação, praticamente sem erros de deriva de longo prazo. Portanto, a calibração do MAC é realizada por meio de uma comparação de um contador acionado por MAC e o pulso PPS fornecido por GNSS. Demorar mais para a comparação nos permite alcançar uma maior precisão de calibração para o MAC. Obviamente, isso leva em consideração que o MAC é um sistema linear invariante no tempo.

Neste diagrama de blocos, você pode ver um sinal de 10 MHz do relógio de rubídio entrando no mecanismo do tempo. Este sinal de clock pode ser substituído por uma entrada SMA de 10 MHz. O sinal do relógio alimenta um módulo de relógio digital e um PLL digital (12,5x resultou de 25 para cima e dividido por 2), resultando em uma frequência de 125 MHz. Os 125 MHz (períodos de 8 nanossegundos) alimentam a unidade ToD.

A unidade ToD associa os incrementos de 8 nanossegundos em valores digitais de 0b000001, uma vez que o LSB (bit menos significativo) está associado a 250 picossegundos (acionado a partir de 32 bits de precisão de subsegundos no gPTP).

Por outro lado, o sinal PPS que vem filtrado do GNSS é usado para capturar o resultado dos incrementos. Se 125 MHz for preciso, os incrementos acumulados devem resultar em intervalos de exatamente 1 segundo. No entanto, na realidade, sempre há uma incompatibilidade entre o valor acumulado e um intervalo teórico de 1 segundo.




Os valores podem ser ajustados usando um loop de controle PI (proporcional e integral) interno. O ajuste pode ser feito alterando o valor 0b000001 em etapas de 250 picossegundos ou ajustando o PPL 12,5x. Além disso, ajustes adicionais (mais ajustados) podem ser aplicados direcionando o oscilador de rubídio.

Quanto mais tempo um GNSS não está disponível, mais a precisão do tempo é perdida. A taxa de deterioração da precisão do tempo é chamada de remanescente. Normalmente, o atraso é descrito como um período de tempo para a precisão e quanto tempo leva para excedê-lo. Por exemplo, o remanescente de um MAC está dentro de 1 microssegundo por 24 horas. Isso significa que após 24 horas, a precisão do tempo não é determinística, mas precisa em 1 microssegundo.

Como alternativa, contamos com a nova geração de relógios atômicos miniaturizados e em escala de chip com capacidade de receber entradas PPS. Isso permite que o mecanismo de tempo do cartão de tempo entregue a sintonização de ultraprecisão do oscilador de alta estabilidade para o componente, em vez de usar recursos digitais para atingir o alvo.

Como princípio geral, quanto mais preciso for o ajuste, melhor será o desempenho remanescente que pode ser alcançado. Em termos de entrega, o uso de uma NIC com temporização de precisão garante que os pacotes de rede recebam registros de data e hora muito precisos, o que é crítico para manter o tempo preciso, pois é compartilhado com outros servidores na rede. Tal NIC também pode receber um sinal PPS diretamente do cartão de ponto.

Depois de conceituar a ideia e várias iterações de implementação, fomos capazes de montar um protótipo.

O aparelho de tempo em ação

O cartão de tempo permite que qualquer máquina x86 com uma NIC capaz de estampagem de tempo de hardware seja transformada em um dispositivo de tempo. Este sistema não depende de ser executado para NTP, PTP, SyncE ou qualquer outro protocolo de sincronização de tempo, uma vez que a precisão e estabilidade fornecida pelo cartão de ponto é suficiente para quase todos os sistemas.

A beleza de usar placas PCIe é que a configuração pode ser montada até mesmo em um PC doméstico, desde que haja slots PCIe suficientes disponíveis.

O próximo passo seria instalar o Linux. O driver do cartão de ponto está incluído no kernel Linux 5.15 ou mais recente. Ou pode ser criado a partir do repositório OCP GitHub no kernel 5.12 ou mais recente.

O driver irá expor vários dispositivos, incluindo o relógio PHC, GNSS, PPS e relógio atômico serial:

$ ls -l / sys / class / timecard / ocp0 /

lrwxrwxrwx. 1 root 0 3 de agosto dispositivo 19:49 -> ../../../0000:04:00.0/

-r – r – r–. 1 root 4096 3 de agosto 19:49 gnss_sync

lrwxrwxrwx. 1 root 0 3 de agosto 19:49 i2c -> ../../xiic-i2c.1024/i2c-2/

lrwxrwxrwx. 1 root 0 3 de agosto 19:49 pps -> ../../../../../virtual/pps/pps1/

lrwxrwxrwx. 1 root 0 3 de agosto 19:49 ptp -> ../../ptp/ptp2/

lrwxrwxrwx. 1 root 0 3 de agosto 19:49 ttyGNSS -> ../../tty/ttyS7/

lrwxrwxrwx. 1 root 0 3 de agosto 19:49 ttyMAC -> ../../tty/ttyS8/

O driver também nos permite monitorar o cartão de tempo, o receptor GNSS e o status do relógio atômico e atualizar um novo fluxo de bits FPGA usando o devlink cli.

Resta configurar o servidor NTP e / ou PTP para usar o cartão de ponto como relógio de referência. Para configurar o chrony, basta especificar o atributo refclock:

$ grep refclock /etc/chrony.conf
refclock PHC / dev / ptp2 tai poll 0 trust

E desfrute de um servidor NTP Stratum 1 muito preciso e estável:

fontes $ chronyc
210 Número de fontes =1
Nome MS / endereço IP Stratum Poll Reach LastRx Última amostra
=========================================================================================
# * PHC0 0 0 377 1 + 4ns [+ 4ns] +/- 36ns

Para o servidor PTP (por exemplo, ptp4u), primeiro será necessário sincronizar o cartão de tempo PHC com o NIC PHC. Isso pode ser feito facilmente usando a ferramenta phc2sys, que sincroniza os valores do relógio com alta precisão, geralmente ficando dentro de um dígito de nanossegundos:

$ phc2sys -s / dev / ptp2 -c eth0 -O 0 -m

Para maior precisão, é recomendado conectar o cartão de ponto e a NIC à mesma pista de CPU PCIe. Para maior precisão, pode-se conectar a saída PPS do cartão de ponto à entrada PPS da NIC.

Para validar e confirmar a precisão, usamos um dispositivo de validação externo chamado Calnex Sentinel conectado à mesma rede por meio de vários switches e uma antena GNSS independente. Ele pode realizar testes PPS, bem como protocolos NTP e / ou PTP:

A linha azul representa os resultados da medição NTP. A precisão permanece dentro de ± 40 microssegundos ao longo do intervalo de medição de 48 horas.

A linha laranja representa os resultados da medição PTP. O deslocamento é praticamente 0 variando dentro da faixa de nanossegundos.

Na verdade, quando comparamos 1 PPS entre a saída do cartão de tempo e a referência interna do Calnex Sentinel, vemos que o erro combinado varia em ± 200 nanossegundos:

Mas o que é ainda mais importante é que essas medições demonstram estabilidade das saídas do aparelho de tempo.

No caso de perda de sinal GNSS, precisamos nos certificar de que a variação do tempo (também conhecida como remanescente) do cartão de tempo com suporte atômico permaneça dentro de 1 microssegundo a cada 24 horas. Aqui está um gráfico que mostra o resquício do relógio atômico (SA.53s) em um intervalo de 24 horas. Como você pode ver, o desvio do PPS permanece dentro de 300 nanossegundos, que está dentro das especificações do relógio atômico.

O design modular do cartão de ponto permite a troca do relógio atômico por um oscilador de cristal controlado por forno (OCXO) ou um oscilador de cristal com compensação de temperatura (TCXO) por uma solução econômica com o compromisso das capacidades remanescentes.

Abrir o código do design do dispositivo de tempo

Construir um dispositivo muito preciso, barato e sem bloqueio do fornecedor foi uma conquista por si só. Mas queríamos ter um impacto maior na indústria. Queríamos realmente libertá-lo e torná-lo aberto e acessível para todos, de um cientista pesquisador a um grande data center em nuvem.

É por isso que nos envolvemos com o Open Compute Project (OCP) para criar um novo Time Appliance Project (TAP). Sob o guarda-chuva do OCP, abrimos o código-fonte do repositório GitHub do Time Appliance Project, incluindo as especificações, esquemas, mecânica, BOM e o código-fonte. Agora, desde que imprimir o PCB e soldar componentes minúsculos não pareça assustador, qualquer um pode construir seu próprio cartão de ponto por uma fração do custo de um aparelho de tempo normal. Também trabalhamos com vários fornecedores, como Orolia, que irá construir e vender cartões de ponto, e Nvidia, que está vendendo o ConnectX-6 Dx com temporização de precisão (e o BlueField-2 DPU com temporização de precisão).

Publicamos uma especificação do Open Time Server em www.opentimeserver.com, que explica em detalhes como combinar o hardware (cartão de ponto, placa de rede e um servidor comum) e o software (driver do sistema operacional, NTP e / ou servidor PTP ) para construir o aparelho de tempo. Construir um dispositivo com base nesta especificação dará controle total aos engenheiros que fazem a manutenção do dispositivo, melhorando o monitoramento, a configuração, o gerenciamento e a segurança.

O dispositivo de tempo é uma etapa importante na jornada para melhorar a infraestrutura de tempo para todos, mas há mais a ser feito. Continuaremos a trabalhar em outros elementos, incluindo a melhoria da precisão e exatidão da sincronização de nossos próprios servidores, e pretendemos continuar compartilhando esse trabalho com a comunidade de computação aberta.