[EMAIL PROTECTED] writes: > I've googled for this problem and generally it seems to be caused by a > networking problem, although I can't see anything that would indicate > that. I'm running ubuntu , with only a couple of changes from the > default configuration... uncommenting the pool NTP server, and adding a > local ISP ntp server. I've been playing with this all afternoon, and > I've come against a dead end. I'll probably realise I've done something > stupid as soon as I send this off :-) > # ntpq -c rv > assID=0 status=c624 sync_alarm, sync_ntp, 2 events, > event_peer/strat_chg, > version="ntpd [EMAIL PROTECTED]:4.2.0a+stable-8-r Fri Sep 9 16:44:48 UTC 2005 > (1)"?, > processor="i686", system="Linux/2.6.12-9-386", leap=11, stratum=16, > precision=-19, rootdelay=0.000, rootdispersion=13.275, peer=7780, > refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000, > poll=6, clock=0xc84a82b7.98087442, state=3, offset=-25.048,
"state=3" (I might be wrong) means that the client has detected a frequency spike and is further monitoring time samples before it does any adjustments. Usually you should see "state=4". [...] Ulrich _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
