Sincronização de tempo em um ambiente heterogêneo

Question 1

[EDITAR] Uma grande reescrita com referências, pois acabei de anotar a resposta antiga de memória.

Resposta curta: não.Atualmente, não é possível obter precisão de quase milissegundos de um sistema operacional comum em uma plataforma x86/x64.

ISENÇÃO DE RESPONSABILIDADE Esta é uma resposta para leigos, pois sou um administrador de sistema comum com uma visão de administrador de sistema comum dos computadores. Um nível profissional de conhecimento sobre cronometragem é provavelmente encontrado entre alguns desenvolvedores de kernel e arquitetos de hardware.

Resposta longa:

É preciso começar em algum lugar. Farei isso de cima para baixo, começando com os aplicativos descendo em direção ao(s) oscilador(es).

O primeiro problema não é ter cronometragem em um computador, mas conseguir fazer com que o ambiente como um todo concorde com qualquer cronometragem que você tenha. Que cronometragem? Acontece que existem algumas maneiras de manter a hora em um computador atual. O que mais vemos é a hora do sistema (exibida em um dos cantos da tela). Vamos começar fingindo que é tão simples e complicar as coisas alguns parágrafos abaixo.

Queremos que a hora do sistema esteja correta e uniforme em todos os nossos computadores. Precisamos de uma maneira de comunicá-lo a partir de uma fonte confiável em um nível tão granular que atenda aos nossos requisitos, sejam eles quais forem.

Vamos colocar nossa exigência em um nível de tolerância de 1ms, ou seja, nosso tempo pode desviar 1ms dentro do nosso ambiente ou perderemos uma meta crítica. Vamos ser concretos e ver o que a Microsoft pode fazer por nós.

Excluindo obsoletos como o NT, o Windows nativo executa sua cronometragem com base em ntp simplificado (computadores ingressados no domínio começando com XP/2003) ou sntp simplificado (computadores não ingressados no domínio começando com Win2k) - obrigado a @Ryan por escolher esse detalhe .Microsoft estabeleceu dois objetivosao fazer a implementação da cronometragem, nenhum dos quais inclui o nível de precisão desejado:

"Não garantimos e não oferecemos suporte à precisão do serviço W32Time entre nós em uma rede. O serviço W32Time não é uma solução NTP completa que atenda às necessidades de aplicativos urgentes. O serviço W32Time foi projetado principalmente para fazer o seguindo:

Faça o protocolo de autenticação Kerberos versão 5 funcionar.
Fornece tempo de sincronização flexível para computadores clientes.

O serviço W32Time não pode manter com segurança o tempo de sincronização no intervalo de um a dois segundos. Tais tolerâncias estão fora das especificações de design do serviço W32Time."

OK. Supondo que estejamos executando sua pilha de serviços em mais de um computador e tenhamos um nível de tolerância de cronometragem próximo a 1 ms para correlação de eventos, isso é uma grande decepção. Se a pilha de serviços incluir dois computadores, não poderemos usar a cronometragem nativa do Windows. Mas já que estamos nisso, vamos enfatizar um ou dois pontos-chave sobre a cronometragem nativa do Windows e incluir alguma documentação completa:

Se você tiver um AD observe que o horário em um determinado domínio será sincronizado a partir da função PDC Emulator, qualquer DC que o possua. Portanto, trazer a hora correta para o domínio precisa ser feito por meio do Controlador de Domínio executando a função de Emulador PDC. Se estiver em uma floresta multidomínio, isso se traduz no emulador PDC do domínio raiz da floresta. A partir daí, o tempo é disperso principalmente para os emuladores PDC de subdomínios e para cada membro do domínio em forma de leque (com algumas ressalvas). Este processo édocumentado aqui. Informações ainda mais detalhadasaqui

OK. O que podemos fazer?

Para começar, precisamosumououtromaneira mais precisa de sincronizar o tempo em todo o ambiente. Supondo que não possamos executar o Linux ntpd ountpd para Windowsvocê poderia dar uma olhada em um cliente shareware chamadoTardis, mas provavelmente há muitos mais por aí para tentar.

Rodamos o Tardis em um servidor Win2k3 rodando como emulador PDC que tinha um clock CMOS com uma inclinação muito grande, por razões históricas inexplicáveis não tivemos escolha a não ser sincronizar toda a rede a partir dele. Agora ele foi substituído com grande alegria por um ntpd Linux dedicado trazendo o tempo de relógios atômicos externos, mas Tardis nos salvou admiravelmente naquele momento.Não sei, entretanto, se isso poderia ajudá-lo a obter uma precisão maior que a nativa do Windows.

Mas vamos supor, a partir deste ponto, que nós descobrimos como implementar um substituto perfeito para a sincronização de horário da rede. Através da sua astúcia inerente, tem capacidade para níveis de tolerância inferiores a um milissegundo. Nós o implementamos para impor como nosso AD espera que o tempo se espalhe pela rede.

Isso significa que podemos obter diagnósticos precisos de sistemas operacionais e microsserviços com uma granularidade que se aproxima de milissegundos?

Vejamos como os sistemas operacionais na arquitetura x86/x64 agendam o tempo do processador.

Eles usam interrupções, que sãoferas multifacetadas ricas em substância arqueológica. No entanto, o sistema operacional não está sozinho no desejo de interromper. O hardware também deseja interromper e tem os meios para isso! (Olá teclado) E os sistemas operacionais acompanham.

É aqui que fica complicado e vou resolver isso simplificando demais. Questões? Eu me abaixo, cubro e aponto para você umabsolutamente excelente tratado sobre o assunto. (Se você está procurando milissegundos em uma plataforma Windows, você realmente deveria lê-lo.) Uma versão atualizada para Win8.1/Win2012r2 ésupostamente em obrasmas nenhuma data de lançamento ainda apareceu.

OK, interrompe. Sempre que algo acontecer em um sistema operacional, uma interrupção aciona a ação a seguir. A ação é um conjunto de instruções buscadas no kernel, que podem ser executadas em ummuitodemaneiras diferentes. O resultado final é que, apesar da interrupção acontecer em um momento que pode ser determinado com mais ou menos precisão, dependendo da arquitetura de hardware e do tratamento de interrupções do kernel, o momento exato em que as partes subsequentes da execução acontecem geralmente não pode. Um conjunto específico de instruções pode ser executado logo após a interrupção ou mais tarde, pode ser executado em uma sequência previsível ou não, pode ser vítima de hardware com bugs ou drivers mal escritos, afetando latências difíceis de reconhecer. Na maioria das vezes simplesmente não se sabe. O carimbo de data/hora no nível de milissegundos que aparece no arquivo de log subsequente -é muito preciso, mas é preciso saber quando o evento aconteceu?

Vamos parar brevemente na interrupção da cronometragem. Uma interrupção vem com um nível de prioridade, o nível mais baixo é onde os aplicativos do usuário (como um serviço padrão) obtêm seu tempo de processador. Os outros níveis (superiores) são reservados para hardware e para trabalho do kernel. Se chegar uma interrupção em um nível acima do mais baixo, o sistema fingirá que não existem interrupções de prioridade mais baixa também na fila (até que as interrupções de prioridade mais alta tenham sido atendidas). Os aplicativos e serviços comuns em execução serão, dessa forma, os últimos da fila em termos de tempo de processador. Em contraste, a prioridade quase mais alta é dada à interrupção do relógio. A atualização do horário quase sempre será feita em um sistema. Esta é uma simplificação quase criminosa de como tudo funciona, mas atende ao propósito desta resposta.

O tempo de atualização consiste, na verdade, em duas tarefas:

Atualizando a hora do sistema / também conhecido como relógio de parede / também conhecido como o que eu digo quando alguém me pergunta que horas são / também conhecido como a coisa que o ntp mexe um pouco para frente e para trás em relação aos sistemas próximos.
Atualização da contagem de ticks, usada, por exemplo, ao medir durações na execução de código.

Mas seja o tempo de parede ou a contagem de ticks, de onde o sistema obtém o tempo? Depende muito da arquitetura de hardware. Em algum lugar do hardware, um ou vários osciladores estão funcionando, e esse tique-taque é acionado viaumdediversospossívelcaminhosem uma interface para contato com o kernel, pois com maior ou menor precisão e exatidão atualiza seu tempo de parede e contagem de ticks.

Existem vários modelos de design para posicionamento de osciladores em um sistema multicore, o principal diferenciador parece ser o posicionamento síncrono versus assíncrono. Estes, juntamente com seus respectivos desafios para cronometragem precisa, são descritosaquipor exemplo.

Resumindo, a cronometragem síncrona possui um clock de referência por multicore, que distribui seu sinal por todos os núcleos. A cronometragem assíncrona possui um oscilador por núcleo. É importante notar que os mais recentes processadores Intel multicore (Haswell) usam alguma forma de design síncrono usando um barramento serial chamado "QuickPath Interconnect" com "Forwarded Clocking", ref.Ficha de dados. O Forwarded Clocking é descrito em termos tais que um leigo (eu) pode obter uma compreensão rápida e superficial deleaqui.

OK, então com todo esse nerderismo fora do caminho (que serviu para mostrar que cronometragem é uma tarefa prática complexa com muita história viva sobre isso), vamos olhar ainda mais de perto o tratamento de interrupções.

Os sistemas operacionais interrompem usando uma de duas estratégias distintas: ticking ou tickless. Seus sistemas usam um ou outro, mas o que significam os termos?

Marcando grãosenviar interrupções em intervalos fixos. O sistema operacional não pode medir o tempo com uma resolução mais precisa do que o intervalo de ticks. Mesmo assim, o processamento real envolvido na execução de uma ou várias ações pode conter um atraso maior que o intervalo de tick. Consideremos, por exemplo, sistemas distribuídos (como microsserviços), onde os atrasos inerentes às chamadas entre serviços podem consumir relativamente muito tempo. No entanto, cada conjunto de instruções estará associado a uma ou várias interrupções medidas pelo sistema operacional em uma resolução não superior ao tempo de execução do kernel. O tempo de tick tem um valor base, mas pode, pelo menos no Windows, ser diminuído sob demanda por um aplicativo individual. Esta é uma ação associadanão só com benefícios, mas também com custos, e carregaum pouco de letras miúdascom isso.

Assim chamadogrãos sem cócegas(que têm um nome pouco descritivo) são uma invenção relativamente nova. Um kernel sem tickless define o tempo de tick em intervalos variáveis (a maior duração possível no futuro). A razão é que o sistema operacional permite dinamicamente que os núcleos do processador entrem em vários níveis de suspensão pelo maior tempo possível, com o simples propósito de economizar energia. "Vários níveis" incluem instruções de processamento em velocidade máxima, processamento em taxas reduzidas (ou seja, velocidade de processador mais lenta) ou não processamento. Diferentes núcleos podem operar em taxas diferentes e o kernel tickless tenta deixar os processadores o mais inativos possível, mesmo em casos que incluem enfileiramento de instruções para dispará-los em lotes de interrupção. Em resumo, diferentes núcleos em um sistema multiprocessador podem variar no tempo em relação uns aos outros. É claro que isso prejudica a boa cronometragem e é até agora um problema não resolvido com as arquiteturas de processador de economia de energia mais recentes e os kernels sem tickless que lhes permitem economizar energia de forma eficiente. Compare isso com um kernel ticking (intervalo de tick estático) que ativa continuamente todos os núcleos do processador, independentemente de eles receberem trabalho real ou não, e onde a cronometragem carrega um grau de imprecisão, mas em um grau relativamente confiável em comparação com kernels sem tickless.

O padrãoO tempo de tick do Windows - essa é a resolução do sistema - é de 15,6 msaté o Windows 8/2012, onde o comportamento padrão é tickless (mas pode ser revertido para ticking do kernel). Acredito que o tempo de tick padrão do Linux depende da compilação do kernel, maseste nichoébem fora da minha experiência(eEstetambém), então você pode querer verificar se você depende disso. Acredito que os kernels do Linux sejam compilados sem tickless a partir de 2.6.21 e podem ser compilados com vários sinalizadores otimizando o comportamento sem tickless (e dos quais me lembro apenas de algumas variantes de no_hz).

Chega de sistemas bare metal. Em sistemas virtuais, a situação fica pior, pois a contenção de VMs e hipervisores de diferentes maneiras torna extremamente difícil a cronometragem precisa. Aqui estáuma visão geral do VMwareeaqui está um para RHEL KVM. O mesmo vale para sistemas distribuídos. Os sistemas em nuvem sãoainda mais difíciljá que não chegamos nem perto de ver hipervisores e hardware reais.

Para concluir, obter o tempo exato de um sistema é um problema de múltiplas camadas. Indo agora de baixo para cima de um ponto de vista de alto nível, temos que resolver: Sincronização de tempo interno entre o hardware e o kernel, interrupções de processamento e atrasos na execução das instruções que desejamos, se em um ambiente virtual imprecisões devido ao encapsulamento de uma segunda camada do sistema operacional, a sincronização de tempo entre sistemas distribuídos.

Portanto, neste ponto da história da computação, não obteremos precisão de milissegundos em uma arquitetura x86/x64, pelo menos não usando nenhum dos sistemas operacionais comuns.

Mas quão perto podemos chegar? Não sei e deve variar muito entre os diferentes sistemas. Controlar a imprecisão dos próprios sistemas específicos é uma tarefa difícil. Basta olharcomo a Intel sugere que o benchmarking de código deve ser feitover que sistemas comuns, como aqueles que administro, estão muito fora de controle nesta perspectiva.

Eu nem sequer penso em conseguir"Todas as funcionalidades de otimização de energia, tecnologia Intel Hyper-Threading, escalonamento de frequência e modo turbo foram desativadas"em sistemas críticos, muito menos mexer em wrappers de código em C e executar testes de longo prazo para obter respostas subsequentes. Eu apenas tento mantê-los vivos e aprender o máximo que posso sobre eles, sem perturbá-los muito. Obrigado carimbo de data / hora, sei que não posso confiar totalmente em você, mas sei que você não está muitos segundos atrasado. Quando a precisão real em milissegundos se torna importante, uma medida não é suficiente, mas é necessário um número maior de medições para verificar o padrão. O que mais podemos fazer?

Por fim, é interessante observarcomo o pessoal do sistema operacional em tempo real pensa na latência de interrupção. Há também umalternativa de sincronização de tempo muito emocionanteem andamento, onde há bastante coisa interessanteEstatisticas,metodologiaewhitepaperssão tornados públicos. Adicione a isso a arquitetura de hardware futura e os desenvolvimentos do kernel e em alguns anos essa questão da precisão da cronometragem poderá não ser mais um problema tão grande. Pode-se ter esperança.

Answer