usenet@jaloob.com 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 4.2.0a@1: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