Facebook divulga novo serviço de horário

O Facebook divulgou um novo serviço de horário NTP no endereço time.facebook.com. Segundo a empresa, ele tem precisão maior do que outros serviços públicos de horário e não identifica usuários por endereço IP. Além disso, o Facebook publicou em seu blog de engenharia um texto relacionado a esse serviço. (em inglês)

O motivo de grandes empresas de TI como o Facebook se interessarem por serviços de horário é a operação de sistemas distribuídos. Para processar transações em bancos de dados distribuídos ou garantir logging correto, vários servidores precisam manter seus relógios sincronizados com alta precisão.

O Facebook comprou equipamentos profissionais de teste Stratum 1 (dispositivos que recebem diretamente informações de tempo de relógios atômicos em satélites) e realizou um benchmark comparando o ntpd, tradicionalmente muito usado como servidor de horário, com o chrony ( https://chrony.tuxfamily.org/ ), um daemon NTP relativamente mais novo. O ntpd, após a inicialização, apresentou temporariamente um erro de -10 ms e depois convergiu gradualmente para um erro de ±1 ms, enquanto o chrony manteve a maior parte dos erros continuamente dentro de ±0,2 ms, mostrando-se muito mais preciso do que o ntpd.

O chrony também tem outras vantagens. A principal é o suporte a hardware timestamping. O NTP, protocolo de sincronização de tempo, tenta obter a hora atual com a maior precisão possível calculando a diferença de tempo de ida e volta com base em timestamps registrados cada vez que pacotes trafegam entre servidor e cliente. Porém, em sistemas que não são de tempo real, não é possível garantir que o atraso de processamento de alguma etapa ficará abaixo de um certo nível. Isso também afeta o NTP e é uma das causas do aumento de erro na sincronização de tempo pela rede.

No entanto, algumas NICs (placas de rede) oferecem suporte a hardware timestamping. Nesse caso, a própria NIC mantém seu clock com hardware dedicado e processa os timestamps, com latência de processamento de apenas alguns nanossegundos. Em um cenário ideal de rede local, se tanto o servidor NTP quanto o cliente oferecerem suporte a hardware timestamping, seria possível sincronizar o tempo com erro inferior a 1 microssegundo. Na prática, como serviços reais de horário não operam em rede local e muitas vezes a NIC do cliente não oferece esse recurso, não dá para esperar esse nível de precisão; ainda assim, segundo o benchmark que combinou chrony com hardware timestamping, a maior parte dos erros de sincronização ficou dentro de ±0,1 ms.

Por isso, o Facebook afirma que oferece seu serviço público de horário com uma configuração do chrony com hardware timestamping ativado. Enquanto outros servidores públicos de horário, como os do Google e da Apple, às vezes ultrapassam um erro de ±2 ms, o serviço do Facebook na maioria dos casos fica dentro de ±1 ms. Como referência, esse serviço opera com endpoints distribuídos em cinco regiões diferentes. Para mais detalhes, consulte o texto original.

[ryuheechul]

Uau. Foi um texto interessante. O esforço em busca de precisão foi compartilhado de forma sucinta (?) e ao mesmo tempo detalhada. Depois de ler este texto, mudei o servidor NTP do meu Mac para time3.facebook.com.

[kunggom]

Estou usando time1.facebook.com. Quando testei com ping, do segundo ao quinto endpoint diferente não respondiam ao ping ou eram bem lentos. Ao configurar time1.facebook.com como servidor de horário no chrony, o erro estimado aparece como pouco mais de ±1 ms. Se eu simplesmente configuro time.facebook.com, ele não consegue obter a hora.

[kunggom]

Só para referência, outros servidores de tempo, como time.google.com ou time.windows.com, sem exceção apresentam um erro de mais de 30 ms. O mesmo vale para pools de NTP como kr.pool.ntp.org. Entre os servidores de tempo que vi até agora, o que apresentou o menor desvio foi o servidor Stratum 1 ntp.postech.ac.kr, que o chrony estimou em cerca de ±5 ms.

[kunggom]

Recentemente descobri que, ao usar time.apple.com como Pool no chrony, são selecionados servidores NTP de alta precisão localizados na Coreia e no Japão. E, nada menos, aparecem como Stratum 1. Parece que a Apple instala receptores GPS nos próprios servidores de CDN e os usa como servidores de tempo.

[xguru]

Nossa, isso é interessante. A expressão at Facebook scale já está ficando familiar.

[kunggom]

Mudando de assunto, vi que este post não foi publicado no Twitter do GeekNews; existe algum critério específico para as notícias que o bot do Twitter publica?

[xguru]

Ah, conferi aqui e o erro veio porque, na parte que corta e publica verificando a quantidade de caracteres, a URL no começo do conteúdo foi convertida automaticamente em link, então acabou passando do limite de caracteres e a API do Twitter retornou erro ;_;

No Twitter, URLs são sempre convertidas para algo como 22 bytes.

Acho que vou ter que corrigir essa parte, aff.