[Bloat] Kirkwood BQL?
Alan Jenkins
alan.christopher.jenkins at gmail.com
Wed Jul 29 07:36:31 EDT 2015
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
More information about the Bloat
mailing list