Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel

[Dave Taht <dave.taht@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]

Dear Mario:

I read over the thread, don't have the energy to join the forum... Please
forward?

1) The patch in that thread increases the default minimum quantum to 500.
It should, IMHO, be available go down to 64U, and I in general get better
results with smaller quantums than the default. Although 64 is a too small,
256 is not bad.

2) Wifi had 4 queues, not one, it is interesting to setup one fq_codel
queue per queue. The various forms of the debloat script do this.

3) "Codel" and "FQ_codel" should not be used synonomously. Codel is a drop
strategy, great for controlling queue length. FQ codel combines flow
queueing (which interleaves flows together, so, for example, a dns packet
or a gaming packet leaps to the head of a queue) with codel, the
combination of which seems to be really, really good, if you have minimal
driver buffering.

4) The problem on wifi/3g/lte/etc is that there is so much extra buffering
at the driver and hardware level that hooking up fq_codel to it is like
shaking at the end of a very, very long hose. Some of these phone wifi
chips are hooked up via a vastly overbuffered usb bus. Shake all you want
at one end of the hose, not a lot will happen.

But: It might help a little and I'd love to know more.

It would help if people fiddling with this stuff would take a gander at
talks by van jacobson, eric dumazet and myself on the subject.

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos

http://netseminar.stanford.edu/

http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be



That said, I'm delighted people are making a start at working on android. I
hope myself to get some time this pring to fiddle with android, and I loved
seeing the documentation on how to patch in fq_codel on the referred
thread. Learning how to hack on a new embedded OS is hard.


Simply starting to measure the available buffering in the stack on a given
chipset would be good. You can do that by shortening the txqueue and trying
an upload, while measuring the delay with ping. Then repeat with a longer
txqueuelen, and you can bracket how much buffering lies below to a large
extent.

The bufferbloat crowd has smashed excess buffering throughout the tcp,
qdisc, and ethernet and ADSL portions of the stack over the past year. It
would be grand to get some insight as to what else to smash. It's like
wackamole, only more fun....
On Tue, Feb 26, 2013 at 1:27 PM, Jonathan Morton <chromatix99@gmail.com>wrote:

> Since the phone only has control of the bottleneck in the upload
> direction, a browse + upload or ping + upload or VoIP + upload test would
> be appropriate. It's important to control the link speed as much as
> possible to be the same for equivalent tests, and to try several different
> network conditions.
>
> Tests involving heavy downlink traffic would measure bloat at the cell
> tower, or at the ISP or access point for wifi tests.
>
> - Jonathan Morton
>  On Feb 26, 2013 7:58 PM, "Mario Ferreira" <liouxbsd@gmail.com> wrote:
>
>> Hi,
>>
>>   After a small exchange, AK kernel developer has added fq_codel to his
>> Galaxy Nexus kernel distribution.
>>
>> http://forum.xda-developers.com/showthread.php?t=2163790
>>
>>   Now, he would like to know how to benchmark it to see the advantages. :)
>>
>>   I know basic tests for desktop: mtr, netalyzr.icsi.berkeley.edu and
>> download + browsing..
>>
>>   What do you suggest for a wireless only setup such as Android Phone?
>>
>>   Best regards,
>>     Mário Sérgio
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>


-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 5462 bytes --]