On 29/07/15 12:24, Alan Jenkins wrote:
On 29/07/15 05:32, Rosen Penev wrote:
Anyone know what the situation is with kirkwood and BQL? I found a
patch for it but have no idea if there are any issues.
I have such a system but have no idea how to ascertain the efficacy
of BQL.
To the latter:
BQL works for transmissions that reach the full line rate (e.g. for
1000MB ethernet). It limits the queue that builds in the
driver/device to the minimum they need. Then queue mostly builds in
the generic networking stack, where it can be managed effectively e.g.
by fq_codel.
So a simple efficacy test is to run a transmission at full speed, and
monitor latency (ping) at the same time. Just make sure the device
qdisc is set to fq_codel. fq_codel effectively prioritizes ping, so
the difference will be very easy to see.
I don't know if there's any corner cases that want testing as well.
BQL can be disabled at runtime for comparison testing:
http://lists.openwall.net/netdev/2011/12/01/112
There's a BQL tool to see it working graphically (using readouts from
the same sysfs directory):
https://github.com/ffainelli/bqlmon
My Kirkwood setup at home is weak, I basically never reach full link
speed. So this might be somewhat academic unless you set the link
speed to 100 or 10 using the ethtool command. (It seems like a good
idea to test those speeds even if you can do better though). You
probably also want to start with offloads (tso, gso, gro) disabled
using ethtool, because they aggregate packets.
a quick test with a 100M setting, connected to gigabit switch, and flent
tcp_download, shows ping under load increases to about 8ms. Conclusion:
the Debian kirkwood kernel probably isn't doing BQL for me :).
Flent can do this test and generate pretty graphs, including a time
series (plot type "all_scaled") and frequency distribution for the
ping ("ping_cdf"). Flent is a frontend to the netperf network
performance tester. You could use a directly connected laptop and run
your own netperf server (netserver command). You'll need to set up
static IPs on both ends for the duration... if headless then make sure
you have an alternative console access :).
The normal Flent test is RRUL, which is two-way. tcp_2up would be
better, to avoid testing both end's BQL at the same time. If you want
to run tcp_2up the other way round, so you only need netserver on the
ARM, try using '--swap-up-down'.
Alan
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat