[GTER] ntpdate vs ntpd (aka, ntpd pra que?)

Danton Nunes danton.nunes at inexo.com.br
Sat Feb 14 15:57:59 -02 2015


On Sat, 14 Feb 2015, Evandro Nunes wrote:

> sei que em linhas gerais o ntpdate tem sido descontinuado em alguns linux e
> em algumas recomendacoes, inclusive do Nic.Br, em favor do ntpd como
> cliente.

acho que eles não se comparam, suas funções são bem diferentes. o ntpdate 
acerta o relógio uma vez e acabou. o ntpd sincroniza o relógio com 
servidores externos e além disso estima a deriva do relógio local em 
relação à UTC. é como comparar uma prancha de skate com uma Harley 
Davidson Fat Boy 1500cc.

> entao o que sobra é a sincronia continua vs periodica como maior diferenca

a maior vantagem do ntpd é a estimativa do drift que você nem menciona. 
isso só é possível com o estimador que lida com dados no tempo e não só em 
um dado instante.

> eu tenho feito um teste simples e pratico, rodando ntpd e ntpdate em
> maquinas distinas, no caso do ntpdate eu rodo:
>
> - @reboot (just in case...)
> - @hourly
>
> dizem que um servidor deveria atrasar 1 segundo a cada ano, e alguns dizem
> com que HZ do kernel acima de 2000 esse atraso pode chegar a 1.89 segundos
> ao ano, ou seja @hourly deveria ser mais que suficiente e a sincronia
> continua do ntpd nao parece justificavel savo intervencao explicita no
> relogio do sistema

de onde saiu essa coisa de 1 segundo a cada ano? o atraso ou avanço 
depende do drift e ele pode ser bem maior que 1s/ano.

> - ha 6 semanas hoje, nao ha qualquer diferenca de horario entre os
> servidores com ntpdate e com ntpd
>
> - a afirmacao acima e baseada em um loop ridiculo rodando date com sleep 5,
> ou seja janela de 5 minutos contra @hourly do ntpdate o que deveria dar uma
> vantagem pro ntpd mas na pratica nao nao deu

sleep 5 = 5 segundos, não 5 minutos. você compara até que fração decimal 
de segundo? ntpd com boa conexão à internet deve te dar uma medida melhor 
que 20ms.

use o ntptrace para ver como seu ntpd está funcionando.

> - consomo de banda do ntpd e expressivamente maior que do ntpdate, normal,
> por ser continuo, na pratica estou falandod e 12 vezes maior consumo de
> banda, ou seja 1200% a mais de banda; claro a banda é baixissima e pouco
> relevante na vida real, mesmo com muitos e muitos servers, o impacto de pps
> gerado provavelmente seria mais preocupantes que de bps mas ainda assim sao
> 1200% nao da pra ignorar, especialmente se voce mora esta regiao norte do
> pais ou regioes rurais onde satelite é tudo que voce tem...

contínuo em termos. se me lembro bem, em regime permanente o ntpd atualiza 
sua medida de tempo a cada 17 minutos. dois pacotinhos UDP a cada 17 
minutos não se pode considerar grande coisa.

> - mais facil colocar 2 linhas no crontab do que configurar o ntpd.conf

sério? sim, configurar um patinete é mais fácil do que uma Fat Boy.

> so que o ntpd em 99% dos casos, especialmente em linux, sobe em modo
> servidor, ouvindo na porta e com socket udp escancarado pro mundo, sem ACL
> alguma pre-configurada, ou seja la estao meus sites remotos com seus
> speedy, velox, gvt, wifi com o ISP local ou link dedicado nas cidades mais
> expressivas, prontinhos pra serem usados em uma amplificacao ntp

a grande preocupação de segurança aí não é exatamente essa, é limitar a 
funcionalidade desse servidor para que ele não seja abusado como 
amplificador de ataques contra terceiros. e isso vale não só para ntpd 
como para qualquer serviço UDP, por exemplo, DNS.

Esse servidor que ele escancara para o "mundo" é para servir clientes NTP 
em tua própria rede local, de modo que eles possam rodar ntpd ou ntpdate 
sem precisar apelar para um servidor externo.

> sejamos pragmaticos, praticos, sem teorias de sync continuo vs periodico pq
> pra mim, essa questao esta superada e o resultado é o mesmo, precisamente o
> mesmo, sem divergencia de 1 segundo na saida do date, ou seja se houver
> divergencia sao de fracoes de segundos que, enquanto relevante em sistemas
> cientificos, em 99% dos outros casos se é abaixo de 1 segundo não é
> perceptível por sysamdin ou sistema algum, nem OTP

1 segundo é uma pequena eternidade em nosso metiér, melhor ter relógio 
acertado com a hora legal brasileira com precisão bem melhor que isso. 
ntpd te dá 20ms em condições bem precárias, ntpdate você nem tem ideia de 
quanto está errando (estou falando do bendito drift)

> ou seja eu perco alguma coisa (de novo, com pragmatismo) que eu nao
> percebi, usando ntpdate preferencialmente?

perde a estimativa de quanto você está errado, que é muito importante em 
qualquer medida.

faz como você quiser, mas depois não reclama se não conseguir cruzar seus 
logs com terceiros, ou prejudicar um cliente porque o relógio estava 
adiantado 1 maldito segundo.

-- Danton.



More information about the gter mailing list