Diferença de relógio entre servidores Clock skew between servers

ID da causa in-clock-skew · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)

Abrir o card interativo, com figuras e simulações →

Quando cada servidor tem o relógio um pouco diferente, as decisões sobre cooldown, buffs e início de eventos divergem de um servidor para outro.

Por quê Em um servidor cuja sincronização de horário parou, o relógio se afasta dos outros servidores de centenas de ms a alguns segundos → Efeito Passar horários absolutos entre servidores, como o horário em que um buff acaba, faz as decisões divergirem → Na tela Depois de trocar de mapa, o buff some ou o cooldown recomeça

Sintomas: Ação perdida / rollback
Fatores: Latência
Quem é afetado: Só eu
Quando: Em movimento ou ao trocar de mapa
Responsável: Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento): Entre servidores, enviar o tempo restante, sem usar horários absolutos.
O que fazer (Equipe de infraestrutura): Monitorar a sincronização de horário (NTP, chrony), alerta de diferença de relógio entre servidores.
Números de referência: Com a sincronização de horário (NTP, chrony) funcionando, servidores do mesmo data center normalmente ficam a poucos ms uns dos outros. Se a sincronização para ou uma máquina virtual fica pausada por muito tempo e depois volta, a diferença chega a centenas de ms ou alguns segundos.
No gráfico: Subida lenta · Offset do relógio por servidor
Onde olhar: Coletar e comparar, em cada servidor, System time (diferença entre o relógio do sistema e o relógio do NTP), Last offset e Ref time (último momento em que uma medição da fonte de tempo foi aplicada) do chronyc tracking
Confirma se: O offset do servidor com problema difere do dos outros em centenas de ms ou mais, ou o Ref time parou há muito tempo, e as decisões divergentes só aparecem em trocas de mapa que passam por esse servidor
Descarta se: Offset de todos os servidores dentro de alguns ms: aponta para o cálculo de tempo no jogo ou para erro na sincronização do relógio do cliente
Como verificar: Ferramentas de infra (sem precisar do código do jogo)
Saiba mais: O relógio de um servidor pular de uma vez para frente ou para trás é tratado em “Salto do relógio do sistema (step do NTP)”, na camada SO do servidor (kernel).

Fontes

RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification IETF
Em uma LAN rápida, clientes NTP normalmente ficam sincronizados dentro de centenas de µs
chrony – Frequently Asked Questions chrony
O drift de relógios de computadores comuns fica abaixo de 100 ppm, mas em máquinas virtuais pode ser maior; uma VM pausada e retomada pode ficar com o horário errado e precisar de correção por step
clock_gettime(2) — Linux manual page Linux man-pages
CLOCK_REALTIME pode dar saltos descontínuos por mudanças manuais e correções do NTP, e CLOCK_MONOTONIC não é afetado por esses saltos
chronyc(1) chrony
chronyc tracking: System time (diferença entre o relógio do NTP e o relógio do sistema), Last offset (offset estimado na última correção), Ref time (momento em que a última medição da fonte de tempo foi aplicada)

Veja também

Mesma camada: L13 Arquitetura e operação de servidores

Mesmo sintoma (Ação perdida / rollback) em outras camadas

Erro na sincronização do relógio L1 Processo do jogo no cliente
Limite de conexões e portas do gateway NAT na nuvem L5 Equipamentos de rede do data center
Microburst no switch L5 Equipamentos de rede do data center
Ring buffer insuficiente L6 Placa de rede do servidor
Limite de PPS da nuvem excedido L6 Placa de rede do servidor
OOM killer L7 SO do servidor (kernel)
Salto do relógio do sistema (step do NTP) L7 SO do servidor (kernel)
Esgotamento de portas efêmeras em conexões entre servidores L7 SO do servidor (kernel)

Ver o card interativo, com figuras e simulações