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