Ntpd na rede local - Evitando a deriva do relógio causando altos offsets

Question

Eu tenho uma rede local com um microcontrolador ARM como o servidor NTP e tenho um computador desktop rodando com o Ubuntu 16.04 LTS como um cliente NTP.

Quando inicio ntpd -g -c /etc/ntp.conf com o seguinte arquivo de configuração ntp

server 192.168.0.11 minpoll 4 maxpoll 4

O primeiro deslocamento após o ntpd define a hora mostra um resultado muito bom, ou seja, algo abaixo de 1ms. Eu obtenho os valores de deslocamento por ntpq -p .

No entanto, o deslocamento aumenta lentamente até 55 ms após aprox. 1000 segundos Esse alto deslocamento é inaceitável para meu aplicativo. Mas após o deslocamento atingir 55 ms, ntpd parece definir a hora novamente e o deslocamento torna-se suficientemente pequeno e estável (< 1ms). Parece que ntpd deixam os relógios derraparem por um tempo e depois de um (muito) longo período de tempo, o deamon toma medidas contrárias ao desvio do relógio entre o cliente NTP e o servidor NTP.

Usando ntpd -g -c /etc/ntp.conf -f /etc/ntp.drift onde ntp.drift foi gerado por ntpd , o deslocamento permanecerá abaixo de 1ms o tempo todo, ou seja, nenhum aumento linear do deslocamento causado pelo desvio do relógio; o comportamento desejado.

Agora para o meu problema: Na minha aplicação, não podemos deixar ntpd rodar por um tempo para calcular o desvio do relógio após um longo período de tempo, a sincronização deve ocorrer após alguns segundos após a inicialização do cliente NTP e o deslocamento deve permanecer estável.

Como posso obter um deslocamento pequeno e estável com ntpd sem saber exatamente o relógio?

    

Answer 1

Depois de tentar algumas opções diferentes em ntpd ainda ter um atraso muito grande, mudei para cronizo . Meu servidor NTP permaneceu inalterado. Usar chrony me deu uma latência de < 1ms o tempo todo. Eu aumentei o tempo de pesquisa como recomendado por chrony tendo o seguinte arquivo de configuração

### chrony.conf

# Add server
server 192.168.0.11 iburst minpoll -6 maxpoll -6 filter 15 xleave
hwtimestamp eth0 minpoll -6

# Logging
logdir /var/log/chrony
log measurements statistics tracking 

makestep 0.1 3
driftfile /etc/chrony.drift

E comecei o deamon com ./chronyd -f /etc/chrony.conf

    

Answer 2

Um driftfile registra a freqüência do relógio local e é bom ter que discipliná-lo com precisão. O Ubuntu /etc/ntp.conf tem driftfile por padrão.

Anexar iburst à linha do servidor envia alguns pacotes rapidamente na sincronização inicial. Recomendado, especialmente se você não quiser esperar vários minutos pelos primeiros pacotes.

Os scripts de inicialização podem atrasar o início do aplicativo até que o NTP seja sincronizado. Faça isso com uma dependência na unidade ntp-wait systemd. Ou o script ntpwait diretamente.

Seu relatório de um deslocamento crescendo e corrigindo-se soa como o ntpd cruzando seu limiar de etapas, depois definindo a hora em vez de girá-la.

    

Answer 3

Sua falta de relação entre a hora do relógio do seu servidor NTP e a hora UTC do mundo real pode ser a raiz do seu problema. Se o seu servidor NTP não tiver várias fontes do mundo real (independentemente de estarem na Internet ou de um GPS, PPS ou fonte atómica na sua rede local), então não será possível determinar o erro de frequência da sua rede local. próprio relógio, e, portanto, não será capaz de disciplinar seu relógio de forma eficaz.

Você pode trabalhar se essa teoria estiver correta ativando as estatísticas que estão sendo registradas no servidor e no cliente, assim:

statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

Depois, poste seus arquivos de estatísticas e suas configurações em um pastebin ou site semelhante e podemos analisá-los à luz do comportamento que você está vendo.