im obtendo erros em todos os meus clientes NTP.
27 out. 14:44:15 cms2 ntpd [19830]: sincronização perdida
27 out. 15:08:25 cms2 ntpd [19830]: tempo redefinir 0.688591 s
27 out. 15:08:25 cms2 ntpd [19830]: sincronização perdida
27 out. 15:28:45 cms2 ntpd [19830]: tempo redefinir 0.462257 s

Verifiquei várias coisas:

ntpq> rv
status \u003d 0644 leap_none, sync_ntp, 4 eventos, event_peer / strat_chg,
version \u003d "ntpd 4.1.2 @ 1,892 ter. fev 24 06:32:25 EST 2004 (1)",
processador \u003d "i686", system \u003d "Linux2.4.21-32.0.1.ELsmp", salto \u003d 00, stratum \u003d 3,
precision \u003d- 17, rootdelay \u003d 20,179, rootdispersion \u003d 33,180, peer \u003d 29037,
refid \u003d ntpServer1,
reftime \u003d ccb03d7c.ac03ff69 Seg, outubro 27 2008 14:15:40.671, poll \u003d 6,
relógio \u003d ccb03d84.6b1044f1 Seg, outubro 27 2008 14:15:48.418, state \u003d 4,
offset \u003d- 96,471, frequência \u003d 442,496, jitter \u003d 98,288, estabilidade \u003d 5,497


[root @ cms1 root] # tcpdump-n porta UDP 123
tcpdump: listening sobre bond0
10:24:46.786062 10.23.1.30.ntp> 10.23.1.4.ntp: v4 cliente iniciar 3 sondagem 6 PREC -15 (DF) [tos 0x10]
10:24:46.786975 10.23.1.4.ntp> 10.23.1.30.ntp: v4 servidor iniciar 2 sondagem 6 PREC -17 (DF)
10:24:54.786359 10.23.1.30.ntp> 10.23.1.3.ntp: v4 cliente iniciar 3 sondagem 6 PREC -15 (DF) [tos 0x10]
10:24:54.786984 10.23.1.3.ntp> 10.23.1.30.ntp: v4 servidor iniciar 2 sondagem 6 PREC -17 (DF)



root @ cms3 root] # ntpq-p
remoto refid st t quando chegar enquete demora compensar jitter
\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d
LOCAL (0) LOCAL (0) 5 l 42 64 1 0,000 0,000 0,061
+ ntpServer1 172.16.21.210 2 u 18 64 1 0,373 -15,214 3,043
* ntpServer2 172.16.21.210 2 u 19 64 1 0,341 -10,955 2,306



alguma sugestão?
felicidades

Pelo que eu leia seus acontecer quando existe um atraso superior a 128ms.
é possível alterar o thrshold de 128ms?

A mensagem significa que o relógio foi corrigido por mais de 128ms. Seu relógio cerca de 7 décimos de 1 segundo off no pior dos casos que lhe mostrar. É realmente um grande problema? Em caso afirmativo, quanta precisão é realmente necessária? Gostaria de não tomar qualquer acção, a menos que o relógio foi mais de uma plena segunda desligado.

Desde o seu jitter parece pouco, o meu palpite é que o relógio do sistema está executando lento. Converse com o fabricante. Pode haver um procedimento para ajustá-lo.

ya eu sei que não é crítico
mas a minha questão principal é pegar carona do alarme:
mesmo assim por acaso você sabe como pode esta mensagem de erro específica pode ser ignorado pelo / var / log / messages?
Felicidades