netdev - Re: [PATCH net] tcp: fix excessive TLP and RACK timeouts from HZ rounding

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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 !