prep for cutting a release, target 2019-01-13

[Achim Gratz]

Eric S. Raymond via devel writes:
> It's all coming back to me now.  We couldn't reproduce this when you
> first reported it, either.  I tried auditing the interval-change rules in the
> code, but couldn't find any bad smell to investigate further.

Well, please tell me if you found some code that would move the poll
interval back to the configured value.  The peer in question still gets
polled, just at a very long interval, so if there's code to recover on
each successful poll, that interval should get shorter.  That never
happens and I couldn't find any code to do that.

> I don't doubt you're seeing *something*.  But it seems to depend on some
> fact pattern the rest of us have never replicated.  I'm at a loss what to
> do about this.

I can pull the info from my posts if you wish.  But as a short summary,
the server sends a "rate exceeded" KOD package (or the client interprets
the server response in that way), hpoll gets set to 10 in response to
that and the actual poll interval is at least 1024s (the longest I've
seen was poll=13 or somewhat over two hours).

> Usually in these situations I just keep adding instrumentation until
> something jumps out and says "boo".  How reliably can you reproduce
> this.

I see at at least once a week usually.  I can try and provoke it by
restarting several servers at the same time and/or configuring burst
back in.  But unless some code gets intrumented I don't see how to get
additional information from that exercise.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html