Quando o ntp atualizará o horário

Question

Eu tenho duas máquinas debianhe wheezy na mesma LAN que têm relógios sincronizados usando o NTP. Usando date , vejo que os horários estão sincronizados. Em seguida, defino o tempo de volta cerca de 30 segundos usando date --set em uma das máquinas.

Quando o serviço ntp corrigirá o relógio? Já faz cerca de 15 minutos e as duas máquinas ainda têm uma diferença de 30 segundos na saída de date . Eu sei que posso forçar uma atualização de relógio, mas quero saber com que rapidez o serviço ntp atualizará o relógio automaticamente.

Veja alguns status:

root@unassigned-hostname:# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 materialinmotio .CDMA.           1 u  621 1024  377   78.039  18621.9 18622.5
 hadb2.smatwebde 200.98.196.212   2 u  451 1024  377   36.824  18621.8 18622.1
 ntp.newfxlabs.c 216.218.192.202  2 u   25 1024  377   69.693  18623.6 17241.1
 time.tritn.com  216.218.192.202  2 u  284 1024  377   69.584    0.466 7038.56
root@unassigned-hostname:# service ntp status
NTP server is running.

e meu /etc/ntp.conf:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#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


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

    

Answer 1

O cliente que você exibiu não está sincronizado com nenhum servidor (não há nenhum marcador * na primeira coluna). Todos foram solidamente alcançados nas tentativas anteriores (alcance = 377, o valor máximo). No entanto, o daemon verificará somente a cada 1024 segundos (intervalo de sondagem) porque foi configurado ou o tempo do cliente ficou estável e, na melhor das hipóteses, ainda está a 400 segundos (quando = 621).

Quando o cliente descobre que o tempo está totalmente errado, ele começará a reduzir o tempo para o valor correto. Se tiver sorte, também o intervalo de sondagem volta ao valor inicial, para que possa sincronizar com segurança mais rapidamente.

Eu apenas tentei voltar o tempo em uma caixa de reposição aqui. Eu vejo que o meu sistema ainda está sincronizado com o seu upstream ( * na primeira coluna), mas o deslocamento foi para 30004.6 (ou seja, 30 segundos) e o jitter aumentou para 30000.3. O tempo de votação não foi reduzido, então será necessário pelo menos mais um ciclo de 1024 segundos para perceber que ele passou por um timewarp.

ntpq -pn                                                                                        

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+5.196.160.139   145.238.203.14   2 u  211 1024  377    0.879  30004.6 30000.3
*195.154.79.192  222.217.153.8    2 u  607 1024  377    5.140   -0.937   1.479
+91.134.209.213  149.202.97.123   3 u  452 1024  377    0.848   -0.540   1.604
-10.20.3.131     163.172.28.46    4 u  901 1024  376    7.189    0.395   0.954

Agora, algumas horas depois, meu sistema alcançou novamente:

ntpq -pn                                                                                       

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*5.196.160.139   145.238.203.14   2 u  432 1024    7    0.755    1.954   0.049
+195.154.79.192  222.217.153.8    2 u  557 1024    1    4.955   -1.616   0.015
+91.134.209.213  149.202.97.123   3 u  429 1024    7    0.754   -0.328   0.125
 10.20.3.131     163.172.28.46    4 u  174 1024    3    7.023   -0.991   1.023