Re: Fedora Core 5 NTP won't synchronize -- condition reject

dan.jakubiec@xxxxxxxxx wrote:
Hi Darren,

Thanks for the quick response. My answers below:

Darren Dunham wrote:

It's not rejecting the packets, it's rejecting the server. Even though
you've received a valid response to the last 8 poll attempts, the jitter
is still over 1000. Such a server will not be selected for
synchronization.



Ah, I see. That is starting to make some sense. So I tried to study
up a bit on jitter, but perhaps you can enlighten me a bit. My
understanding is that jitter is the time difference detected between
each "read" of the time. What factors would cause my jitter to be so
high and what can I do reduce it?


A delay of 71 ms is fairly large, but shouldn't by itself cause this
problem. Is your pipe to the internet overloaded?


Hmm, good question. I'm not noticing any particular slowness, BUT...
I am running on a cable modem, I live in Hawaii, and my son is playing
Xbox all day long with his friends and using its VoIP stuff. So I
suppose that between all that and communicating with a mainland NTP
server (or farther) might be causing some problems.

But wait: I have two Fedora Linux machines here at my house. I just
started up the other one and it was able to sync up fairly quickly:

ntpq> pe
remote refid st t when poll reach delay offset
jitter
==============================================================================
+srnf0501.asplen 212.94.162.33 3 u 7 64 77 210.373 -3759.7
1.006
*195.244.96.13 225.119.95.255 2 u 7 64 77 226.420 -3748.0
4.659
+roxane.home-dn. 131.188.3.220 2 u 66 64 76 221.002 -3756.7
1.891
LOCAL(0) LOCAL(0) 10 l 62 64 37 0.000 0.000
0.001


ntpq> as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 38956 9414 yes yes none candidat reachable 1
2 38957 9614 yes yes none sys.peer reachable 1
3 38958 9414 yes yes none candidat reachable 1
4 38959 9014 yes yes none reject reachable 1
ntpq>


Meanwhile the jitter on my non-sync'ing machine remains high:

ntpq> pe
remote refid st t when poll reach delay offset
jitter
==============================================================================
pkix-gw.codefab 66.187.224.4 2 u 60 64 377 134.178 -13743.
1404.95
ntp.derobert.ne .GPS. 1 u 61 64 377 153.902 -12337.
1409.28
monster.schulte 128.101.101.101 3 u - 64 377 180.836 -13243.
1202.24
ntpq> as

ind assID status conf reach auth condition last_event cnt
===========================================================
1 56196 9014 yes yes none reject reachable 1
2 56197 9014 yes yes none reject reachable 1
3 56198 9014 yes yes none reject reachable 1
ntpq>



So what gives? Could this be cause by a hardware problem with my
clock?


--
Dan Jakubiec


Check your kernel parameter "HZ". If it's set to 250 or 1000 try setting it to 100. This governs the rate at which your clock interrupts arrive. Some Linux systems will lose clock interrupts if HZ is set higher than 100. This causes the clock to fall behind the correct time. The usual complaint in such cases, however, is that ntpd keeps "stepping" the clock ahead.

BTW, I wouldn't refer to your second machine as "synched up". It has selected a synchronization source but, with an offset of 3748 milliseconds, it's nowhere near being synchronized. If you let it run for several hours it should synchronize.
.

Relevant Pages

  • Re: Question to NTP developers
    ... See the ntpq billboards with truthful tally codes and jitter estimates. ... at least some NMEA drivers do the PPS thing internally and do not rely on the atom driver. ... In such cases you are completely on your own and any errant behavior should be reported to the driver author. ...
    (comp.protocols.time.ntp)
  • Re: NTP "maximum error" on local network
    ... # ntpq -pcrv ... If you don't specify the refid, I believe it defaults to ".LCL.", ".LOCL." ... Even if your local clock was originally set to a time taken from NIST, there is a 99.99999999% probability that the time has since deviated from the correct value. ...
    (comp.protocols.time.ntp)
  • Re: Garmin GPS 18LVC Setup but questions on best way
    ... the ntpq -p output looks like this: ... The PPS line from the GBS-18 LVC is wired to the DCD line of the serial port. ... In my ignorance, I don't see why you even need the SHM driver, but as I said before, I'm no expert! ...
    (comp.protocols.time.ntp)
  • Re: Fedora Core 5 NTP wont synchronize -- condition reject
    ... up a bit on jitter, but perhaps you can enlighten me a bit. ... server might be causing some problems. ... ntpq> pe ... ind assID status conf reach auth condition last_event cnt ...
    (comp.protocols.time.ntp)
  • use NMEA 0183 as time source has 180ms difference
    ... I use garmin gps 15 as ntp time source,the CPU is 486. ... ntpq> rv ... device="NMEA GPS Clock", ...
    (comp.protocols.time.ntp)