Eu configurei o serviço w32time para atuar como um servidor ntp e foi confirmado em pelo menos um outro cliente (MacOS X). Eu usei alguns utilitários diferentes no Windows que indicam que realmente existe um serviço ntp respondendo.
Aqui está um trecho do ntpd (no Qnx, execute como ntpd -ddqn -c ntp.conf):
poll_update: at 1998 192.168.2.10 flags 0081 poll 6 burst 0 last 1998 next 2064
MCAST *****sendpkt(fd=6 dst=192.168.2.10, src=192.168.2.220, ttl=0, len=48)
transmit: at 1998 192.168.2.220->192.168.2.10 modeinput_handler: if=2 fd=6 length 48 from c0a8020a 192.168.2.10 3
receive: at 1998 192.168.2.220<-192.168.2.10 restrict 00
receive: at 1998 192.168.2.220<-192.168.2.10 mode 4 code 1
poll_update: at 1998 192.168.2.10 flags 0081 poll 6 burst 0 last 1998 next 2062
clock_filter: n 2 off 318.028919 del 0.001000 dsp 0.016994 jit 0.094653, age 0
Eu não sou adepto de decifrar isso. Eu espero que alguém possa educar, ou simplesmente me diga o que está errado. Tem que haver uma razão pela qual a implementação Qnx não está sendo sincronizada. Eu acho que posso escolher o pouco sobre o deslocamento (estar na frente 318s) - o que seria correto.
Por que não está consertando o relógio local?
Por quanto tempo você esperou a sincronização acontecer? Pode demorar até 10 minutos em alguns casos. Você pode obter o tempo usando:
# ntpdate <time server ip address>
Para o que vale a pena, a versão QNX dos utilitários do ntp é marginalmente diferente do que está disponível no linux e no mac, são basicamente as mesmas ferramentas construídas com um compilador diferente.
Tags ntp windows-server-2003