O tempo à deriva após o NTP ser configurado

Question

Este é um host XenServer 7.1 CU1 . O NTP deve se comportar como em qualquer outro Linux distro . Nós configuramos /etc/ntp.conf com os seguintes servidores (tentamos outros servidores com resultados semelhantes e esses servidores funcionaram em outro ambiente:

server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org

Depois de reiniciar o serviço, obtemos esses resultados com ntpq -d

[root@c0101 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*tock.usshc.com  .GPS.            1 u   56   64    1   32.936   36.036   0.000
 www.tripout.tec 128.233.154.245  2 u   56   64    1   82.397   46.653   0.000
+t2.time.bf1.yah 98.139.133.62    2 u   57   64    1   17.589   26.316   0.000
 mirrors.switch. 206.108.0.134    2 u   55   64    1   63.777   57.423   0.000

A partir disso, eu posso ver que tock.usshc.com foi escolhido (tem * símbolo de estrela), a enquete está em 62s que é mínima devido a fonte ruim, o deslocamento é alto (desde que eu verifiquei em um servidor em um ambiente diferente e mostra apenas -0,81), o jitter é 0, o que parece estranho, já que em todos os casos eu vi pelo menos um número baixo, como 0.1 , e o atraso parece normal.

Após cerca de dez minutos, nenhum servidor escolheu (nenhum símbolo *) devido a "fontes incorretas", também o deslocamento e o jitter parecem muito ruins:

[root@c0101 ~]# ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 tock.usshc.com  .GPS.            1 u   52   64  205   32.952  6021.94 4422.72
 www.tripout.tec 128.233.154.245  2 u   64   64  377   82.473  5880.01 3724.85
 t2.time.bf1.yah 98.139.133.62    2 u    3   64  377   17.812  6647.80 3704.53
 mirrors.switch. 206.108.0.134    2 u    1   64  377   63.746  6678.59 3723.43

Aqui está o log ntp, que estou tendo dificuldade em entender.

[root@c0101 ~]# cat /var/log/ntp.log
14 Sep 12:01:20 ntpd[3914]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
14 Sep 12:01:20 ntpd[3914]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen and drop on 1 v6wildcard :: UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen normally on 2 lo 127.0.0.1 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen normally on 3 xapi1 10.131.250.22 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listening on routing socket on fd #20 for interface updates
14 Sep 12:01:20 ntpd[3914]: 0.0.0.0 c016 06 restart
14 Sep 12:01:20 ntpd[3914]: 0.0.0.0 c012 02 freq_set kernel 500.000 PPM
14 Sep 12:01:21 ntpd[3914]: 0.0.0.0 c61c 0c clock_step +1014.260362 s
14 Sep 12:18:15 ntpd[3914]: 0.0.0.0 c614 04 freq_mode
14 Sep 12:18:16 ntpd[3914]: 0.0.0.0 c618 08 no_sys_peer
14 Sep 12:19:39 ntpd[3914]: ntpd exiting on signal 15
14 Sep 12:19:39 ntpd[4689]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
14 Sep 12:19:39 ntpd[4689]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen and drop on 1 v6wildcard :: UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen normally on 2 lo 127.0.0.1 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen normally on 3 xapi1 10.131.250.22 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listening on routing socket on fd #20 for interface updates
14 Sep 12:19:39 ntpd[4689]: 0.0.0.0 c016 06 restart
14 Sep 12:19:39 ntpd[4689]: 0.0.0.0 c012 02 freq_set kernel 500.000 PPM
14 Sep 12:19:40 ntpd[4689]: 0.0.0.0 c61c 0c clock_step +1.067923 s
14 Sep 12:19:41 ntpd[4689]: 0.0.0.0 c614 04 freq_mode
14 Sep 12:19:42 ntpd[4689]: 0.0.0.0 c618 08 no_sys_peer
14 Sep 12:22:58 ntpd[4689]: 0.0.0.0 c628 08 no_sys_peer
14 Sep 12:26:11 ntpd[4689]: 0.0.0.0 c638 08 no_sys_peer

Aqui estão resultados adicionais de ntpq -c as e outros que estou tentando entender também.

Eu tenho usado este link para solucionar problemas: link link

    

Answer 1

Conseguimos corrigir isso alterando o clocksource para xen (o hypervisor) em vez de dom0 (a VM de gerenciamento) com /opt/xensource/libexec/xen-cmdline --set-dom0 clocksource=xen

Outra correção mais complicada foi ajustar a frequência de carrapatos. Consulte este link

Eu não tenho muita informação sobre a causa, outra que o NTP não é capaz de ajustar o relógio, pois está se movendo muito rápido devido a algum bug na versão atual, combinado com o uso de alguns tipos de hardware da Dell.

Isso ocorre enquanto a correção é lançada em versões mais recentes.

    

Answer 2

Se esta é uma máquina virtual, certifique-se de:

1. Você tem tinker panic 0 definido no seu ntp.conf ( NOTA: esta DEVE ser a primeira linha do arquivo conf!). Isso evitará que o ntpd resgate se o relógio chegar a um ponto distante. E ...

2. Verifique se você não está executando no modo de giro (ntpd -x). O modo de giro tentará fazer ajustes graduais, em vez de acelerar o relógio. Isso pode ser um problema em VMs se o relógio estiver se deslocando mais rápido do que a taxa de variação.