On Tue, Aug 02, 2022 at 12:27:57PM -0600, Theo de Raadt wrote:
> I think you intend for that to be two seperate diffs, not merged into
> one.
>
> For connect < 15 seconds, I think that is a bit strict.
>
> For IO stalling 15 seconds, I suspect such IO stalls happen more than
> we know, and will d
On Tue, Aug 02, 2022 at 12:27:57PM -0600, Theo de Raadt wrote:
> I don't see any way this can be tested in less than 24 hours.
Good idea.
I've set up a fast testrig that runs two instances in parallel in a
'while true' loop (with and without the changeset), each with their own
cachedir on MFS.
I
I think you intend for that to be two seperate diffs, not merged into one.
For connect < 15 seconds, I think that is a bit strict.
For IO stalling 15 seconds, I suspect such IO stalls happen more than we
know, and will do harm to RPKI processing results.
I don't see any way this can be tested in
On Tue, Aug 02, 2022 at 03:59:40PM +0200, Claudio Jeker wrote:
> What makes you think that 15sec is enough to open connections in all
> scenarios? I feel this is one of those changes that just shows that
> maybe the current connect timeout from the system is too conservative.
Yeah, maybe. How abou
On Tue, Aug 02, 2022 at 01:42:43PM +, Job Snijders wrote:
> Hi,
>
> We were doing a lot of waiting in connect() for some (currently) broken
> repositories. Move on with life after MAX_CONTIMEOUT seconds.
>
> This changeset reduces the real time spent fetching the RIPE TAL (with
> hot cache) f
Hi,
We were doing a lot of waiting in connect() for some (currently) broken
repositories. Move on with life after MAX_CONTIMEOUT seconds.
This changeset reduces the real time spent fetching the RIPE TAL (with
hot cache) from 7m14.57s to 3m20.10s on an IPv4+IPv6 dual-stacked host.
This changeset
