lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CANn89iJRCaZzzdWedQ1uEyiW3CgxFA2sEi=BCjOscLj8s6YjXQ@mail.gmail.com> Date: Mon, 16 Oct 2023 09:57:18 +0200 From: Eric Dumazet <edumazet@...gle.com> To: Neal Cardwell <ncardwell.sw@...il.com> Cc: David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org, Neal Cardwell <ncardwell@...gle.com>, Yuchung Cheng <ycheng@...gle.com> Subject: Re: [PATCH net] tcp: fix excessive TLP and RACK timeouts from HZ rounding On Sun, Oct 15, 2023 at 7:47 PM Neal Cardwell <ncardwell.sw@...il.com> wrote: > > From: Neal Cardwell <ncardwell@...gle.com> > > We discovered from packet traces of slow loss recovery on kernels with > the default HZ=250 setting (and min_rtt < 1ms) that after reordering, > when receiving a SACKed sequence range, the RACK reordering timer was > firing after about 16ms rather than the desired value of roughly > min_rtt/4 + 2ms. The problem is largely due to the RACK reorder timer > calculation adding in TCP_TIMEOUT_MIN, which is 2 jiffies. On kernels > with HZ=250, this is 2*4ms = 8ms. The TLP timer calculation has the > exact same issue. > > This commit fixes the TLP transmit timer and RACK reordering timer > floor calculation to more closely match the intended 2ms floor even on > kernels with HZ=250. It does this by adding in a new > TCP_TIMEOUT_MIN_US floor of 2000 us and then converting to jiffies, > instead of the current approach of converting to jiffies and then > adding th TCP_TIMEOUT_MIN value of 2 jiffies. > > Our testing has verified that on kernels with HZ=1000, as expected, > this does not produce significant changes in behavior, but on kernels > with the default HZ=250 the latency improvement can be large. For > example, our tests show that for HZ=250 kernels at low RTTs this fix > roughly halves the latency for the RACK reorder timer: instead of > mostly firing at 16ms it mostly fires at 8ms. > > Suggested-by: Eric Dumazet <edumazet@...gle.com> > Signed-off-by: Neal Cardwell <ncardwell@...gle.com> > Signed-off-by: Yuchung Cheng <ycheng@...gle.com> > Fixes: bb4d991a28cc ("tcp: adjust tail loss probe timeout") Reviewed-by: Eric Dumazet <edumazet@...gle.com> It is a bit sad that some distros are still using HZ=250 in 2023. Thanks Neal !
Powered by blists - more mailing lists