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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
