NTP está funcionando, o relógio do sistema ainda não está no tempo - o que dá?

Um servidor Debian Stable (5.0.3) está sendo executado ntpde conectado à Internet. Ainda assim, o relógio do sistema está errado cerca de 5 minutos.

$ /etc/init.d/ntp status
NTP server is running..

Partes relevantes (eu acho) de /etc/ntp.conf:

driftfile /var/lib/ntp/ntp.drift

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

server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org

Eu sei que o NTP não necessariamente traz o relógio no tempo imediatamente. Ainda, quantas horas ou dias você precisa esperar para razoavelmente esperar que o NTP tenha feito seu trabalho e sincronizado o relógio?

Estou perdendo algum outro arquivo ou opção de configuração ou apenas fazendo algo errado? O ntp (em vez de, por exemplo, o ntpdate ) é a ferramenta certa para isso? Existe alguma maneira rápida de verificar se a configuração está correta e se os servidores NTP escolhidos retornam a hora correta?

Edit : saída de ntpq -pis:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.nexellent.n .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-madrid .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 sinister.wzw.tu .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-frankf .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Edit 2 : Acontece que o ntpdate -u 0.europe.pool.ntp.orgcomando ( sugerido por brent ) retorna

17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found

... mesmo em outras máquinas que comandam funcionem bem. Portanto, veremos as configurações de rede / firewall para este servidor específico (que está em uma rede diferente, acessada pela VPN).

Resolução : o culpado não era o firewall local em nosso servidor, mas as configurações de firewall em algum lugar da rede ao redor. Por isso, pedimos ao provedor de hospedagem de servidores que permitisse o NTP para nossas máquinas, e agora ele funciona bem. Por exemplo, ntpq -pagora retorna:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.eunet.fi    192.36.144.23    2 u   10   64    1    1.043    0.258   0.001
 ns2.eunet.fi    62.142.10.44     2 u    9   64    1    0.671    0.135   0.001
 ns3.eunet.fi    62.142.10.44     2 u    8   64    1    0.750    0.277   0.001

(Também mudamos para servidores eunet.fi reiniciados pela empresa de hospedagem, mas isso não vem ao caso.) Os comandos na resposta de brent foram úteis porque me fizeram perceber que o problema estava no acesso de rede aos servidores NTP, não na configuração NTP em si. Obrigado a todos!

Pare o ntpd, execute ntpdate -u 0.europe.pool.ntp.org3 vezes, inicie o ntpd, verifique ntpq -p, o atraso, o deslocamento e a tremulação devem ser diferentes de zero.

Se eu tivesse que adivinhar o porquê e supondo que você tenha conectividade de rede e possa ver o seu NTP Host sem nenhum problema, pode ser que você tenha se desviado para um grande valor. Se a diferença horária for maior que X (Desculpe, não me lembro o que X é improvável), um aviso será impresso e a hora não será sincronizada. Você pode verificar suas mensagens de syslog para ver se há casos disso.

Se esse for o caso, interrompa o NTP, execute o host ntpdate e reinicie o NTPD. Isso forçará uma sincronização de tempo e começará a mantê-lo sincronizado daqui para frente, se você continuar a desviar tanto, poderá ter um problema de hardware.

As colunas "alcance", sendo 0, sugerem que não foi possível conversar com os servidores; iirc gradualmente recebe bits para mostrar como foram as últimas 8 tentativas (então 377 é bom, 0 é ruim).