Re: [Bloat] Kirkwood BQL?

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

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