netdev - Re: [PATCH net-next v3] tcp: use RFC6298 compliant TCP RTO calculation

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 for Android: free password hash cracker in your pocket

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

Message-ID: <d2568bd1-1722-fa7d-9870-279e2e5ef6fb@mytum.de>
Date:	Wed, 29 Jun 2016 22:18:28 +0200
From:	Daniel Metz <dmetz@...um.de>
To:	Yuchung Cheng <ycheng@...gle.com>,
	Hagen Paul Pfeifer <hagen@...u.net>,
	Daniel Metz <Daniel.Metz@...de-schwarz.com>
Cc:	netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v3] tcp: use RFC6298 compliant TCP RTO
 calculation

>                                       B        D      R     Y
> ------------------------------------------------------------------------------
> mean TCPRecovLat      3s      -7%   +39% +38%
> mean TCPRecovLat2    52s     +1%   -11%  -11%

This is indeed very interesting and somewhat unexpected. Do you have any 
clue why Y is as bad as R and so much worse than B? By my understanding 
I would have expected Y to be similar to B. At least tests on the Mean 
Response Waiting Time of sender limited flows show hardly any difference 
to B (as expected).

Also, is a potential longer time in TCPRecovLat such a bad thing 
considering your information on HTTP response performance?