Como posso medir e impedir o desvio do relógio?

15

Em várias plataformas de produção, observamos sintomas que parecem sugerir que a hora do dia está saltando periodicamente para frente ou para trás. Os saltos são tipicamente em torno de 1 segundo, geralmente cancelam (pulam para frente e para trás muito em breve) e acontecem cerca de 50 vezes por dia. Esse desvio é mais perceptível durante períodos de pico de uso de aplicativos e durante períodos de altas operações de E / S de disco, como backups diários. Esses desvios estão afetando nosso aplicativo confidencial em tempo real.

Os sistemas são servidores Oracle Netra X4250 e Netra X4270 executando o SLES 11SP2 com o kernel 3.0.58-0.6.6 padrão.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Desativamos o NTP , mas isso não teve nenhum efeito nos desvios. Existem ferramentas que medem o desvio do relógio da hora do dia? Como podemos evitar isso?

Essas são plataformas de produção e não podemos recriar o problema em nossos laboratórios; portanto, minha capacidade de experimentar é limitada. Se deixado por conta própria, escreverei uma ferramenta para medir a deriva e, talvez, experimente uma fonte de relógio HPET .

linux sles clock

— brett
fonte

5

Desativar o NTP torna os relógios muito mais instáveis ... a única razão pela qual vejo o NTP para não manter o relógio alinhado é que o relógio está fora de sintonia e o NTP se recusa a atualizá-lo (consulte ntpdate(8)ou ntpd(8)).

— vonbrand

1

O NTPD rastreia e corrige o desvio do relógio, mas o que você tem não é o desvio. A deriva é consistentemente na mesma direção, aproximadamente a mesma quantidade ao longo do tempo. Se ele pular aleatoriamente para frente e para trás, não há como prever e acomodar.

— Patrick

1

O que o @Patrick disse está certo, o problema que você descreve é um salto descontínuo no tempo para frente e para trás, várias vezes por dia. O NTP funciona bem na deriva, mas não ajuda muito nisso. Algo provavelmente redefinirá a data do sistema para uma fonte de tempo externa que talvez tenha apenas 1 segundo de resolução. Se seus servidores forem x86 *, o RTC de hardware pode ser a fonte e algum cron é o culpado. No que se refere à medição do deslocamento do relógio, a resposta ntpdate de Bratchley é uma abordagem razoável, desde que seja usada uma boa referência de relógio do estrato 1: execute uma vez por minuto e gnuplote o resultado para uma imagem.

— 31415 duanev

1

Deparou com essa avaliação do NTP iniciando em um novo servidor ( drdobbs.com/embedded-systems/… ). Leva horas NTP para aprender um novo cristal. Para cristais realmente ruins, o NTP terá que "acelerar" o relógio em quantidades significativas várias vezes durante o treinamento (consulte as Figuras 4 e 5 nesse artigo). Um valor final em ntp.drift de 118ppm é 10 segundos por dia ou 208ms a cada 30 minutos. Embora isso não seja o que o OP estava vendo, o NTP pode inicialmente causar saltos visíveis no tempo.

— duanev 29/07

8

Existem ferramentas que medem o desvio do relógio da hora do dia?

As únicas ferramentas que eu conheço são as ferramentas NTP que devem ser suficientes. Na verdade, você não precisa configurar o ntpd para sincronizar com uma determinada fonte de relógio; basta usar a -dopção ntpdatepara buscar o deslocamento calculado.

Exemplo:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d é a opção de depuração que o NTP funciona sem realmente tocar no relógio do sistema.

Algum conselho sobre como podemos evitar isso?

Não estou muito surpreso que você não consiga reproduzir isso em ambientes de desenvolvimento / teste, pois provavelmente é apenas devido ao relógio do hardware. Se você tiver suporte de hardware com alguém, eu tentaria reparar suas máquinas. Uma possibilidade é trocar uma das máquinas de desenvolvimento por essa máquina de produção, consertar os sistemas anteriores do PROD e reintroduzi-la como uma máquina de desenvolvimento para substituir a que está no PROD agora.

Além disso, mudar a fonte do relógio de hardware é tudo o que você pode fazer. Se você não pode ou não pode fazer a troca, eu sugiro que você siga a rota hpet. Você pode testar se a alteração da fonte do relógio interfere nos serviços do sistema e, em seguida, implantá-la na produção como um elogio.

— Bratchley
fonte

Por "medir o desvio do relógio", não quis dizer desvio de uma fonte de tempo de referência, como o NTP fornece. Eu quis dizer uma ferramenta que pode detectar "saltos" no horário do dia em um intervalo de tempo contínuo. Por exemplo, faça amostragens por hora do dia a cada 50ms e relate se a diferença da última amostragem está muito longe de 50ms. Essa ferramenta mostraria se a hora do dia está se afastando do relógio de hardware subjacente por qualquer motivo.

— Brett

1

A presença de tal intervenção provavelmente não causaria mais degradação do desempenho do que você espera resolver? Com toda a probabilidade, porém, é um problema de hardware, portanto, você precisará obter a manutenção do hardware ou usar uma fonte de relógio sem esse problema. tscé baseado na CPU, portanto, faz sentido que uma atividade mais alta da CPU desencadeie um problema com o relógio do hardware. Se o hpet for rápido o suficiente para você, talvez seja necessário tentar, fazer manutenção ou fazer a troca. Essas são as únicas opções que posso ver para você.

— precisa saber é o seguinte

3

Uma solução é usar HPET

Consulte também Temporizador de eventos de alta precisão

Para defini-lo como parâmetro de inicialização, use

clocksource=hpet

Em hardware mais antigo, TSCera frequentemente instável e desabilitado pelo kernel.

Com o advento de CPUs com vários núcleos / hiperencadeados, sistemas com várias CPUs e sistemas operacionais em hibernação, o TSC não pode ser invocado para fornecer resultados precisos ...

Wikipedia: Contador de carimbo de data / hora

Em um sistema de produção exibindo os sintomas de instabilidade do relógio, mudei a fonte do relógio para hpet. Isso não afetou os sintomas observados de tremulação do relógio.

— Brett

HPET é um temporizador de hardware externo e não pode tremer. Portanto, essa solução parece ser um caminho errado. Havia muitos problemas de tempo com o hardware mais antigo, especialmente ao usar a virtualização. Você verificou isso com software diferente também?

1

Escrevi uma ferramenta mais detalhada para correlacionar medições de relógio com sintomas de latência exibidos por nosso aplicativo. Essa ferramenta parece descartar o que eu suspeitava anteriormente como jitter no relógio da hora do dia do Linux.

Para encurtar a história, minha hipótese inicial era inválida. Mas eu aprendi muito sobre os relógios Linux com as respostas e os links, então obrigado a todos que responderam!

— brett
fonte

3

(...) minha hipótese inicial era inválida. Você poderia nos dizer qual era a causa real, então?

— Piotr Dobrogost

0

O relógio não deve ser monótono, a menos que alguém o mude? Saltos para trás não devem ser possíveis. Deve haver algo definindo o relógio - um trabalho cron ou outro daemon (por exemplo, uma chamada para hwclock --adjust). Lembro-me de que o próprio ntp atualiza as estatísticas do desvio e o compensa rotineiramente e, se você não executar o ntp por um longo período de tempo e obter um grande deslocamento, ele perde tempo por dias depois, se você não redefinir /etc/adjtime. Você pode ter algo assim configurado - algo que reajuste o tempo periodicamente (e provoca saltos).

ntp é realmente destinado a combater esse problema.

— orion
fonte

Foi o que eu pensei também. Minha leitura das fontes de clock do hardware sugere que o contador deve aumentar monotonicamente. Se isso fosse verdade, na pior das hipóteses, deveríamos observar taxas de tick erráticas, mas nunca recuaríamos. Em um sistema multiprocessador, entendo que o tsc precisa ser sincronizado entre os processadores - talvez seja isso que esteja causando saltos para trás?

— Brett