> On Jul 6, 2018, at 3:37 PM, Pete Heist <[email protected]> wrote: > > I’m also satisfied for now that this shouldn’t hold us up. However, what I’ll > also want to try next is netem on a separate veth device from cake. I believe > Dave’s veth testing earlier was using three namespaces / veth devices, maybe > for this reason(?)
So under the category of “unsurprising”, with netem as a root qdisc in a separate namespace/veth device from cake, there is no lockup. The attached script creates an environment with 6 namespaces (client, client qdisc, client delay, server delay, server qdisc, server) with veth devices / bridges between. It’s easy to switch the qdisc or netem params, if anyone needs such a thing. 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... Pete
veth_qm.tgz
Description: Binary data
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
