In article [EMAIL PROTECTED],
David L. Mills [EMAIL PROTECTED] wrote:
documentation. The probable cause is dispersion too high or the noselect
option is present. The prefer option has nothing to do with this.
I would have thought the most likely cause was dispersion too *small* not
too large,
David,
The cause is not the intersection algorith, as to be considered and fail
the intersection algorithm the tally code would be x. According to the
current algorithm, the cause would have to be rejection by the unfit()
routine for the causes cited.
With regard to your comments about the
Folkert,
First, temporarily remove all but the SHM driver to simplify debugging.
Then, look at the rv billoard for that association and note the flasher
bits. Then, look at the peer_unfit() routine in ntp_proto.c. The
comments detail the reasons for each bit. More information is in the
Hi,
See this:
remote refid st t when poll reach delay offset jitter
==
+belle.intranet. 192.87.106.2 2 u 251 256 3750.1056.605 0.122
+thegateap.intra 192.87.106.2 2 u 106
Folkert van Heusden wrote:
Hi,
See this:
remote refid st t when poll reach delay offset jitter
==
+belle.intranet. 192.87.106.2 2 u 251 256 3750.1056.605 0.122
Why is the '.SHM.'-clock not even considered? Because of the negative offset?
Negative offsets are not a problem. They happen all the time.
My guess is that something your new driver is setting up
makes your clock look not-very-good. It's probably one of the
obscure constants that aren't well
