Como o Precision Time Protocol está sendo implantado na Meta

A implementação do Precision Time Protocol (PTP) na Meta nos permite sincronizar os sistemas que impulsionam nossos produtos e serviços com precisão de nanossegundos. O antecessor do PTP, o Network Time Protocol (NTP), nos forneceu precisão de milissegundos, mas à medida que escalamos para sistemas mais avançados em nosso caminho para construir a próxima plataforma de computação, o metaverso e a IA, precisamos garantir que nossos servidores mantenham o tempo como com a maior precisão possível. Com o PTP implantado, poderemos aprimorar as tecnologias e os programas da Meta — de comunicações e produtividade a entretenimento, privacidade e segurança — para todos, em todos os fusos horários e em todo o mundo.

A jornada para o PTP durou anos, pois tivemos que repensar como o hardware e o software de cronometragem operam em nossos servidores e data centers.

Estamos compartilhando um mergulho técnico profundo em nossa migração PTP e nossas inovações que tornaram isso possível

Antes de mergulharmos na arquitetura PTP, vamos explorar um caso de uso simples para uma temporização extremamente precisa, para fins de ilustração.

Imagine uma situação em que um cliente grava dados e imediatamente tenta lê-los. Em grandes sistemas distribuídos, as chances são altas de que a gravação e a leitura cheguem a diferentes nós de back-end.

Se a leitura estiver atingindo uma réplica remota que ainda não possui a atualização mais recente, há uma chance de o usuário não ver sua própria gravação:

Isso é no mínimo irritante, mas o mais importante é que isso está violando uma garantia de linearizabilidade que permite a interação com um sistema distribuído da mesma forma que com um único servidor.

A maneira típica de resolver isso é emitir várias leituras para diferentes réplicas e aguardar uma decisão de quorum. Isso não apenas consome recursos extras, mas também atrasa significativamente a leitura devido ao longo atraso de ida e volta da rede.

Adicionar timestamps precisos e confiáveis ​​em um back-end e réplicas nos permite simplesmente esperar até que a réplica alcance o timestamp lido:

Isso não apenas acelera a leitura, mas também economiza toneladas de poder de computação.

Uma condição muito importante para que esse projeto funcione é que todos os relógios estejam sincronizados ou que o deslocamento entre um relógio e a fonte de tempo seja conhecido. O deslocamento, no entanto, muda devido à correção constante, desvio ou simples variações de temperatura. Para tanto, utilizamos a noção de Janela de Incerteza (WOU), onde podemos dizer com alta probabilidade onde está o offset. Neste exemplo em particular, a leitura deve ser bloqueada até o timestamp de leitura mais WOU.

Pode-se argumentar que realmente não precisamos de PTP para isso. NTP fará muito bem. Bem, nós pensamos isso também. Mas os experimentos que realizamos comparando nossa implementação NTP de última geração e uma versão anterior do PTP mostraram uma diferença de desempenho de aproximadamente 100 vezes:

Existem vários casos de uso adicionais, incluindo rastreamento de eventos, invalidação de cache, melhorias na detecção de violação de privacidade, compensação de latência no metaverso e execução simultânea em IA, muitos dos quais reduzirão bastante os requisitos de capacidade de hardware. Isso nos manterá ocupados por muitos anos.

Agora que estamos na mesma página, vamos ver como implantamos o PTP em meta escala.

Após várias análises operacionais e de confiabilidade, chegamos a um projeto que pode ser dividido em três componentes principais: o rack PTP, a rede e o cliente.

Apertem os cintos - vamos mergulhar fundo.

Isso abriga o hardware e o software que atendem aos clientes; o rack consiste em vários componentes críticos, cada um dos quais foi cuidadosamente selecionado e testado.

A antena GNSS é facilmente um dos componentes menos apreciados. Mas este é o lugar onde o tempo se origina, pelo menos na Terra.

Estamos nos esforçando para obter precisão de nanossegundos. E se o receptor GNSS não puder determinar a posição com precisão, não poderá calcular o tempo. Temos que considerar fortemente a relação sinal-ruído (SNR). Uma antena de baixa qualidade ou obstrução ao céu aberto pode resultar em um alto erro de desvio padrão de localização 3D. Para que o tempo seja determinado com extrema precisão, os receptores GNSS devem entrar no chamado modo de tempo, que normalmente requer um erro 3D <10m.