ntpq quirks

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> 
> 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.