Re: SACK performance improvements - technical report and updated 2.6.6 patches

[Craig Partridge <craig@aland.bbn.com>]

Thanks for sharing!

I found the report fun reading in the sense that I don't know of many folks
who've worked on slow path performance improvement.

However, having written some of these kinds of papers in the past, I'll point
out that before it could be considered publishable, it needs a much clearer
explanation of the algorithms in the actual code and precisely how they
were modified.  For instance, it wasn't clear to me if the SACK block
code walked the list of outstanding segments for each SACK block or walked
the list of segments once, checking all the SACK blocks (they are both
n*s algorithms, but the second algorithm will have decidedly better
performance due to locality and ordering tricks you can play).

Also, it was not clear why the revised algorithm grows as O(lost packets)
vs O(cwnd).

Thanks!

Craig

In message <43A7178E.4030808@ev-en.org>, Baruch Even writes:

>Hello,
>
>I wanted to post an update about my work for SACK performance
>improvements, I've updated the patches on our website and added a
>technical report on the work so far.
>
>It can be found at:
>http://hamilton.ie/net/research.htm#patches
>
>In summary: The Linux stack so far is unable to effectively handle
>single transfers on 1Gbps with high rtt links (220 ms rtt is what we
>tested). The sender is unable to process the ACK packets fast enough
>causing lost  ACKs and increased transfer times. Our work resulted in a
>set of patches that enable the Linux TCP stack to handle this load
>without breaking sweat.
>
>Your comments on this work would be appreciated.
>
>Regards,
>Baruch