Hal Murray via devel <[email protected]>:
>
> Anybody familiar with the retransmission code?
I think I'm the only person who has touched it.
> It seems to hang occasionally. A wild guess, there is some backoff code in
> there that increases the retransmission timer. That's good. I'm guessing
> that my problem is that the timer gets too big. It's not actually hanging,
> just running very very very slowly.
Plausible, but I took a look and nothing like that is jumping out at me.
Except maybe this:
# Requests are automatically retried once, so total timeout with no
# response is a bit over 2 * DEFTIMEOUT, or 10 seconds. At the other
# extreme, a request eliciting 32 packets of responses each for some
# reason nearly DEFSTIMEOUT seconds after the prior in that series,
# with a single packet dropped, would take around 32 * DEFSTIMEOUT, or
# 93 seconds to fail each of two times, or 186 seconds.
# Some commands involve a series of requests, such as "peers" and
# "mrulist", so the cumulative timeouts are even longer for those.
That's in pylib/packet.py.
Your boojum is very likely in there, anyway, as opposed to ntpq.py. When
I pulled the old C code apart I hadn't exactly anticipated ntpmon, but
I knew I wantef to bee able to write custom clients so I did my best
to factor all the low-level packet handling into pylib/packet.py.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
[email protected]
http://lists.ntpsec.org/mailman/listinfo/devel
