Hal Murray :
>
> > It's one of the few times I've gone on an expedition like that and
> > completely
> > failed. Whatever it is, it's not going to be obvius.
>
> Here is an interesting possibility. How about the code is working as
> designed
> but the parameters are set wrong. Maybe not "w
> It's one of the few times I've gone on an expedition like that and completely
> failed. Whatever it is, it's not going to be obvius.
Here is an interesting possibility. How about the code is working as designed
but the parameters are set wrong. Maybe not "wrong". How about "not
agressiv
Hal Murray :
> Thanks.
>
> There is another quirk that seems related to retransmissions. I forget the
> details. I'm pretty sure there is bug report on it.
>
>
> > I do remember that there was a very old issue with flaky behavior of ntpq
> > over WiFi that we thought might be due to a bug in
Thanks.
There is another quirk that seems related to retransmissions. I forget the
details. I'm pretty sure there is bug report on it.
> I do remember that there was a very old issue with flaky behavior of ntpq
> over WiFi that we thought might be due to a bug in the fragment reassembly
If I
Hal Murray via devel :
> I only started seeing it recently. It's probably because my DSL line has
> gone
> flaky. I don't remember any recent changes to ntpq, but it seems worthwhile
> to inquire.
I haven't touched that code in many months.
I do remember that there was a very old issue with
I'm seeing things like this when doing ntpq -p to a far away site with lots of
opportunities for lost packets.
***No information returned for association 21216
Has anybody seen anything similar?
I only started seeing it recently. It's probably because my DSL line has gone
flaky. I don't r
