Prized Season software

Tenho o Debian Sarge instalado numa máquina VMware (debian-31r0a-i386-kernel2.6-frog.vmx, nem sempre está disponível, pois está a correr no meu desktop principal - que por motivos óbvios de economia de energia).

Constata-se que a gestão que o VMware faz não tem precisão do relógio. Em resumo o relógio atrasa-se incrivelmente, dependendo igualmente da carga do processador. Como tenho um AMD (AMD Athlon(tm) 64 Processor 3500+, refira-se a frog.../phpsysinfo/) com "Cool & Quiet". este atraso torna-se ainda mais notório.

Desliguei-me das razões para isto acontecer. Só quis remediar a situação. Há várias soluções para resolver este problema, uma das quais à bruta: chamar o programa "ntpdate" de 5 em 5 minutos. Há ferramentas VMware que permitem sincronizar o relógio do guest com o host, mas achei mais interessante navegar nas potencialidades do NTP. Deparei-me com uma instalação fácil do pacote ntpdate, mas o ntp-server, verdadeiramente, não me serviu de nada. Não percebi porquê (embora a instalação também fosse fácil): provavelmente o relógio é tão pouco fiável que o NTP desiste de se tentar sincronizar. Mesmo o 'ntp -q' não funciona; apenas o cliente 'ntpdate' ofereceu uma forma fácil.

O protocolo NTP é realmente potente, mas algo intrincado de se perceber cabalmente. Mais info em frog...doc/.

Analisemos então um caso negativo. cock é a máquina virtual que uso para experiências.

cock:~# ntpdate -q -b 10.0.0.1 | sed 's/.* \([0-9-]*\).* sec/\1/'
24 Feb 23:11:04 ntpdate[2420]: no server suitable for synchronization found
server 10.0.0.1, stratum 16, offset 325.786359, delay 0.02643

(Nota: para usar o ntpdate, instale o pacote Debian com o mesmo nome: 'apt-get install ntpdate)
Descasquemos o comando:

• '-q' : query only, do not set the clock; apenas inquirir o servidor que supostamente está a correr o ntpd (10.0.0.1)
• '-b': use-se directamente settimeofday
  

O comando sed piped mostra o número de segundos de desvio face ao servidor de NTP.
A queixa de que não se encontra nenhum servidor foi devido ao facto do servidor de NTP não ter ainda sincronizado o tempo devidamente: porque tinha sido re-iniciado.
Após cerca de um minuto a mensagem passou a ser diferente.
Vejamos:

cock:~# while :; do ./ntpdate -b 10.0.0.1 | grep sec$ | sed 's/.* \([0-9.-]*\) sec$/\1/' ; sleep 5 ; done
541.791472
3.210474
5.017780
...

É impressionante como em cada 5 segundos há quase 5 segundos de atraso.


Para verificar se um dado servidor está disponível, também pode usar um serviço de tentativa de ligação ao porto 123:
nmap -sU -p123 www.clock.org
...embora o método preferencial seja mesmo
ntpdate www.clock.org ; echo $?
caso o resultado do último comando seja diferente de zero, é porque o NTP ao servidor (neste caso www.clock.org) falhou.