<html><head></head><body>Did you use SACK?<br><br><div class="gmail_quote">On February 17, 2019 12:26:51 PM GMT+01:00, Pete Heist <pete@heistp.net> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Attached are some scripts that run two simple tests of ECN with veth devices, with and without ECN. The topology is:<br><br>client - middlebox (20Mbit htb+fq_codel egress both ways) - net (40ms netem delay both ways, i.e. 80ms RTT) - server<br><br>Here are some results from the APU2 with Debian 9 / kernel 4.9.0-8:<br><br>Test 1 (“One vs one”, two clients uploads competing, one flow each for 60 seconds, measure total data transferred):<br><br> No ECN, 63.2 + 63.5 transferred = 126.7MB<br> ECN, 63.2 + 61.5 transferred = 124.7MB<br><br>Test 2 (“One vs pulses”, client #1: upload for 60 seconds, client #2: 40x 1M uploads sequentially (iperf -n 1M), measure client #1 data transferred):<br><br> No ECN, 63.2 MB transferred<br> ECN, 65.0 MB transferred<br><br>Can anyone suggest changes to this test or a better test that would more clearly show the benefit of ECN? I guess we’d want more congestion and the cost of each lost packet to be higher, meaning higher RTTs and more clients?<br><br>Pete<br></pre></blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>