<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 6, 2016 at 12:20 PM, Steinar H. Gunderson <span dir="ltr"><<a href="mailto:sgunderson@bigfoot.com" target="_blank">sgunderson@bigfoot.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_6908050086592436491gmail-">On Sat, Dec 03, 2016 at 03:24:28PM -0800, Eric Dumazet wrote:<br>
</span><span class="gmail-m_6908050086592436491gmail-">> Wait a minute. If you use fq on the receiver, then maybe your old debian<br>
> kernel did not backport :<br>
><br>
> <a href="https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=9878196578286c5ed494778ada01da094377a686" rel="noreferrer" target="_blank">https://git.kernel.org/cgit/li<wbr>nux/kernel/git/davem/net.git/<wbr>commit/?id=9878196578286c5ed49<wbr>4778ada01da094377a686</a><br>
<br>
</span>I upgraded to 4.7.0 (newest backport available). I can get up to ~45 MB/sec,<br>
but it seems to hover more around ~22 MB/sec in this test:<br>
<br>
  <a href="http://storage.sesse.net/bbr-4.7.0.pcap" rel="noreferrer" target="_blank">http://storage.sesse.net/bbr-4<wbr>.7.0.pcap</a></blockquote><div><br></div><div>Thanks for the report, Steinar. Can you please clarify whether the BBR behavior you are seeing is a regression vs CUBIC's behavior, or is just mysterious?</div><div><br></div><div>It's hard to tell from a receiver-side trace, but this looks to me like a send buffer limitation. The RTT looks like about 50ms, and the bandwidth is a little over 500 Mbps, so the BDP is a little over 3 Mbytes. Looks like most RTTs have a flight of about 2 MBytes of data, followed by a silence suggesting perhaps the sender ran out of buffered data to send. (Screen shot attached.)</div><div><br></div><div>What are your net.core.wmem_max and net.ipv4.tcp_wmem settings on the server sending the data?</div><div><br></div><div>What happens if you try a bigger wmem cap, like 16 MBytes:</div><div><br></div><div>  sysctl -w net.core.wmem_max=16777216 net.ipv4.tcp_wmem='4096 16384 16777216'<br></div><div><br></div><div>If you happen to have access, it would be great to get a sender-side tcpdump trace for both BBR and CUBIC.</div><div><br>Thanks for all your test reports!</div><div><br></div><div>cheers,</div><div>neal</div><div><br></div></div></div></div>