[Cake] lockup with cake and veth

[Pete Heist]

Ok, it ended up being partly that, and mainly needing to increase kernel params for max TCP window memory, otherwise there was a hard limit on what I’d actually end up getting for the TCP window.

Rates start getting finicky with these large TCP windows, go too large and the rates can collapse for some reason, but I have managed to run about 6Gbit with 100ms RTT through Cake this way without a problem, either with a single stream or the aggregate of up to four streams. Or 20Gbit at 20ms RTT.

./qenv.sh on
./run_iperf.sh
./run_flent.sh

> On Jul 6, 2018, at 9:40 PM, Dave Taht <dave.taht at gmail.com> wrote:
> 
> You ran out of queue to store for that rtt.
> 
> netem limit 100000 or higher for that.
> On Fri, Jul 6, 2018 at 12:25 PM Pete Heist <pete at heistp.net> wrote:
>> 
>> Only, I wonder if high BDP links can be emulated with netem. Say I want 10gbit with 100ms rtt. If I use “netem delay 50ms” each direction, rtt is correct, but throughput for iperf3 drops from 30Gbit to 450Mbit. CPU is a few percent, so that’s not the issue. Fiddling with TCP window (iperf3 -w) just seems to make it worse. So I’m still figuring out netem, I guess...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: veth_qm.tgz
Type: application/octet-stream
Size: 1611 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180707/c8bbe693/attachment.obj>