I haven't found what I'm looking for, but this has several comments with
descriptions of the problems I mentioned a week or two ago.
ntpq sloth
https://gitlab.com/NTPsec/ntpsec/-/issues/547
--
These are my opinions. I hate spam.
___
devel mailin
Hal Murray :
> Part of the problem is that there is a lot of cruft in that area. For
> example, grep for CERR_
> There is a clump of signals defined as part of a ControlSession, none are
> ever
> raised, a few are caught. Looks like somebody decided to rename things to
> SERR and never got ar
On 11/20/19 5:44 PM, Hal Murray via devel wrote:
Part of the problem is that there is a lot of cruft in that area. For
example, grep for CERR_
There is a clump of signals defined as part of a ControlSession, none are ever
raised, a few are caught. Looks like somebody decided to rename things
> I don't think I know yet. I lean towards an incremental fix along the lines
> you describe, but it's also possible that there's a serious design flaw that
> merits a rewrite.
The 20,000 ft view looks reasonable, but I think the use of signals is
unreasonably complicating the control flow.
Hal Murray via devel :
> I know what's going wrong, but I'm not enough of a python geek to see a clean
> fix.
>
> The basic idea is that the client sends a request and the server sends back a
> clump of packets. The client specifies the max clump size. What's happening
> is that at least one
I know what's going wrong, but I'm not enough of a python geek to see a clean
fix.
The basic idea is that the client sends a request and the server sends back a
clump of packets. The client specifies the max clump size. What's happening
is that at least one packet of the clump is getting lost
