[GTER] ntpdate vs ntpd (aka, ntpd pra que?)
Patrick Tracanelli
eksffa at freebsdbrasil.com.br
Thu Feb 19 11:36:11 -02 2015
> On 19/02/2015, at 00:50, Gustavo De Nardin (spuk) <gustavodn at gmail.com> wrote:
>
> 2015-02-18 15:56 GMT-02:00 Gustavo De Nardin (spuk) <gustavodn at gmail.com>:
>> 2015-02-15 11:43 GMT-02:00 Evandro Nunes <evandronunes12 at gmail.com>:
>>> 2015-02-15 2:52 GMT-02:00 Gustavo De Nardin (spuk) <gustavodn at gmail.com>:
>>>
>>>> 2015-02-14 15:07 GMT-02:00 Evandro Nunes <evandronunes12 at gmail.com>:
>>>>> preciso validar ou rever minha posicao, entao... o que eu perco? ntpd pra
>>>>> que?
>
> Complementando, outra forma de resolver ao menos parte das questões
> que te incomodam seria usar nos servidores que não servem como fonte
> de tempo um daemon que seja apenas cliente NTP. O Chrony e o OpenNTPD
> podem funcionar apenas como clientes, e o serviço timesyncd do systemd
> só funciona como cliente.
Esquece o ntpdate, mesmo se você quiser rodar via crontab e de alguma forma não quer um daemon a mais rodando (tem que adora subir daemons, tem que os evita) ainda assim o ntpd é mais adequado, rodando com "ntpd -L -g -q”. Você terá um algoritmo mais eficiente fazendo o reference clock dos servidores listados no ntp.conf, ao invés de descartar deviations e “escolher” um servidor de N possíveis que é o que o ntpdate se propõe.
Outra coisa que concordo, o ntpd é realmente chato pra desabilitar listen em *:123, precisa dar ignore em interfaces, wildcards, forçar listen, e realmente o simples hábito de subir daemon por subir acaba colocando mais um serviço ouvindo na rede pq o ntpd é tão chato de não ouvir na rede que a maioria provavelmente não cuida disso.
Mas você não precisa descartar um daemon por causa do NTPD.
Convenhamos e sejamos sinceros, o ntpd é o melhor servidor NTP que temos em termos de recursos. Mas é um dos piores daemons cliente. A convergência dele pra hora correta é longa com grandes saltos, mais longa do que deveria. Exatamente por isso o PHK foi financiado a criar um novo daemon NTP, com tempo de FLL/PLL mais razoáveis.
O ntimed deve levar de 30 a 60 segundos pra ajustar o phase loop e depois em 5 minutos garantir rápida convergência de grandes desvios de tempo do sistema.
O ntimed é muito mais eficiente que o OpenNTP que por sua vez é mais eficiente que o ntpd (em função de cliente, nenhum se equipara ao ntpd pra servidor).
Servidores NTP não são a mesma coisa e se usar o ntpd como cliente de referencia pra testes é natural se decepcionar. Pra todos que querem um daemon ntp eficiente, exclusivamente para modo cliente, sugiro o ntimed-client frente a qualquer outro daemon ntp pra cliente, por experiencia própria e testes.
pkg install ntimed
sysrc ntimed_enable=YES
service ntimed start
Mas lembre-se, ntpd nenhum não é um cão de guarda que vai imediatamente ajustar seu relógio se ele estiver errado. O trabalho é linear e constante, vai ajustando a referencia local do relógio com as referências externas e só seta a hora local quando a referencia local bater com a de sincronia. Isso pode levar até alguns minutos se seu relógio estiver muito deslocado. Lembre-se o daemon ntp esta ai pra normalizar desvios computacionais de horário, e pra corrigir um desvio artificial (setado errado) não será imediato, especialmente se for de vários segundos a minutos de divergência forçada.
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"
More information about the gter
mailing list