From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A926421F0B0 for ; Wed, 27 Feb 2013 22:08:57 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp2so870954pbb.34 for ; Wed, 27 Feb 2013 22:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=+4kcQ5/6hsoCB6JGHW6eYqoUjFozwkWsSP1hTN9rX5g=; b=pL72kW9DFGGIwiMfwp1KrejEwBJDlK29O35GSZtnOdt7Gzf5niud4XznMF3EaP6gks 7IwDOVNN5ANyenhqOAAD11po87gcMtf26bxWwyH7yIoJe3fVofz5GewBCDmAkcRnxvk4 6CaLkYvy5PskJD0mFSLtODXbVrtTCWA0exvWvW9GR8vFHSYJgGqjsiNk5xcFFnTXRsZ6 NEPvc2wk8mM6zu8ZOrSBYeOyvglbrAKklSIdNoh/Zz0uga/bVeit787kb1kDyeC1puTh rSI4QufW3YnnZwnE+pUhu8IIBAMWDAozeqWmiHgAK43fwVsJ3qXre3SKhnTrTzXqOmxq 41nQ== X-Received: by 10.66.2.132 with SMTP id 4mr11580335pau.11.1362031736997; Wed, 27 Feb 2013 22:08:56 -0800 (PST) Received: from [10.0.0.2] (201-88-121-175.bsace702.dsl.brasiltelecom.net.br. [201.88.121.175]) by mx.google.com with ESMTPS id tp2sm7220313pbc.12.2013.02.27.22.08.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 22:08:56 -0800 (PST) Message-ID: <512EF471.4080109@gmail.com> Date: Thu, 28 Feb 2013 03:08:49 -0300 From: =?ISO-8859-1?Q?M=E1rio_S=E9rgio_Fujikawa_Ferreira?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Dave Taht References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090006060008000000060300" Cc: bloat Subject: Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 06:08:57 -0000 This is a multi-part message in MIME format. --------------090006060008000000060300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Here follows preliminary results using vanilla fq_codel by Eric Dumazet merged from Linux mainline. This was posted to the xda forum. fq_codel+upload tests should yield results closer to the ones without an upload. fq_codel should both help maintain better latency than any other scheduling algorithm and work mostly without configuration. The upload speed rates should remain mostly unaffected by fq_codel. The tests were conducted on a stock 4.2.2 maguro Galaxy Nexus with latest AK 3.0.67+~ak.710.422.Cylon kernel. I did the tests between 01:00 and 03:00 local time (GMT-3). root@android:/ # uname -a Linux localhost 3.0.67+~ak.710.422.Cylon #1 SMP PREEMPT Wed Feb 27 06:54:36 CET 2013 armv7l GNU/Linux Read the full post to gather an idea of what to expect. root access is required to perform these series of tests. Here follows a simple upload + several ping/latency test guide. The ping tests are done against 187.7.117.32 (www DOT google DOT com). 1) Install the following applications from Play Store 1.1) Fing 1.2) Net Ping 1.3) Network Latency Checker 1.4) Terminal 2) Copy a huge file to your Galaxy Nexus. We will upload it later to create the upload test environment. 3) Connect your Galaxy Nexus to your WIFI network. 4) Make sure there is no other traffic on your network: no downloads, youtube, nothing. 5) Make sure fq_codel is not enabled. 5.1) Open Terminal 5.2) Type the following commands to make sure fq_codel is disabled su tc qdisc del dev wlan0 root fq_codel tc -s qdisc 5.3) You should get a result similar to the following. The wlan0 qdisc should read pfifo_fast. root@android:/ # su root@android:/ # tc qdisc del dev wlan0 root fq_codel Android does not support qdisc 'fq_codel' root@android:/ # tc -s qdisc Android does not support qdisc 'prio' qdisc pfifo_fast 0: dev rmnet0 root refcnt 2 [cannot parse qdisc parameters] Sent 2889806 bytes 15890 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Android does not support qdisc 'prio' qdisc pfifo_fast 0: dev p2p0 root refcnt 2 [cannot parse qdisc parameters] Sent 8892 bytes 114 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Android does not support qdisc 'prio' qdisc pfifo_fast 0: dev wlan0 root refcnt 2 [cannot parse qdisc parameters] Sent 25272 bytes 438 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 6) Let's stablish a baseline. We will conduct all tests without any traffic on your network. Furthermore, note that fq_codel is not enabled. 7) Start Fing 7.1) Click Gear Icon 7.1.1) Host Tools -> Ping -> 187.7.117.32 7.2) Copy the results somewhere 8) Start Net Ping 8.1) Settings 8.1.1) Packet Count -> 100 8.1.2) Statistics -> Enable 8.1.3) Click Back 8.2) Ping 187.7.117.32 8.3) Copy the results somewhere 9) Start Network Latency Checker 9.1) Select 100 request , 0s delay , DNS 9.2) Click Check 9.3) Copy the results somewhere 9.4) Select 100 request , 0s delay , HTTP 9.5) Click Check 9.6) Copy the results somewhere 10) On your Galaxy Nexus, add the huge file from step 2 to your Google Drive. The upload will begin immediatly. If the upload finishes during any test, remove the file from Google Drive, upload it again then restart the given test. 11) Repeat Fing test 11.1) Copy the results somewhere 12) Repeat Net Ping test 12.1) Copy the results somewhere 13) Repeat Network Latency Checker test 13.1) Copy the results somewhere 14) Enable fq_codel. If the upload finishes, remove the file from Google Drive and upload it again. 14.1) Open Terminal 14.2) Type the following commands to make sure fq_codel is disabled su tc qdisc add dev wlan0 root fq_codel tc -s qdisc 14.3) You should get a result similar to the following. The wlan0 qdisc should read fq_codel. root@android:/ # su root@android:/ # tc qdisc del dev wlan0 root fq_codel Android does not support qdisc 'fq_codel' root@android:/ # tc -s qdisc Android does not support qdisc 'prio' qdisc pfifo_fast 0: dev rmnet0 root refcnt 2 [cannot parse qdisc parameters] Sent 2889806 bytes 15890 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Android does not support qdisc 'prio' qdisc pfifo_fast 0: dev p2p0 root refcnt 2 [cannot parse qdisc parameters] Sent 8892 bytes 114 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Android does not support qdisc 'fq_codel' qdisc fq_codel 8001: dev wlan0 root refcnt 2 [cannot parse qdisc parameters] Sent 525997 bytes 6231 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 15) Repeat Fing test 15.1) Copy the results somewhere 16) Repeat Net Ping test 16.1) Copy the results somewhere 17) Repeat Network Latency Checker test 17.1) Copy the results somewhere ----- For instance, here follows my personal results. The upload tests were conducted with a 150Mb upload to Google Drive as fast as my ADSL would allow it. My ADSL has an upload max speed rate of 512KiB. 1) Fing 1.1) Results with neither upload nor fq_codel 64 average ping 6% package loss 60 minimum ping 112 maximum ping 0 std dev ping 5 estimated hops 1.2) Results with upload but without fq_codel 226 average ping 2% package loss 68 minimum ping 580 maximum ping 2 std dev ping 5 estimated hops 1.3) Results with both upload and fq_codel 180 average ping 6% package loss 67 minimum ping 510 maximum ping 3 std dev ping 5 estimated hops 2) Net Ping 2.1) Results with neither upload nor fq_codel 187.7.117.32 min-max: 60.6-161ms 187.7.117.32 avg/stddev: 69.9/15.1ms 2.2) Results with upload but without fq_codel 187.7.117.32 min-max: 69.6-510ms 187.7.117.32 avg/stddev: 251/110ms 2.3) Results with both upload and fq_codel 187.7.117.32 min-max: 68.5-454ms 187.7.117.32 avg/stddev: 220/93.4ms 3) Network Latency Checker: 100 request , 0s delay , DNS 3.1) Results with neither upload nor fq_codel Min: 166 Max: 9338 Avg: 554 3.2) Results with upload but without fq_codel Min: 176 Max: 9306 Avg: 629 3.3) Results with both upload and fq_codel Min: 82 Max: 9649 Avg: 554 4) Network Latency Checker: 100 request , 0s delay , HTTP 4.1) Results with neither upload nor fq_codel Min: 260 Max: 3280 Avg: 342 4.2) Results with upload but without fq_codel Min: 239 Max: 10021 Avg: 1017 4.3) Results with both upload and fq_codel Min: 81 Max: 3477 Avg: 560 The Network Latency Checker results present fq_codel as the best possible option on all cases. This was unexpected. I repeated those tests several times but fq_codel was always the best. I'll have to further review the Network Latency Checker tests. Can you reproduce these "weird" results? I can say that I am really satisfied with fq_codel on Android. It gave better performance than plain pfifo_fast with little extra cost. You can also try the exact same tests using 3G instead of WIFI. Replacing wlan0 with rmnet0 on the aforementioned steps should be enough. Check which interface is UP when you're using radio with the "netcfg" command on Terminal. I reached out to bufferbloat mailing list for suggestions on how to better test and tune the code for Android phones. :) Please, do not hesitate to suggest improvements or corrections to this post. One problem I have is that I "cannot" know beforehand what's the available upload bandwidth on the current radio connection (3G) so I cannot limit the upload to avoid intrinsic upload buffering as I would do with my home Tomato router. Something just occured to me. I apologize if it's stupid, naive or simply already exists: auto detect the available radio (2G/3G/4G) upload bandwidth . 1) Inquiry the reported connection speed from the phone radio and use it as our high water mark. 2) Use a variation of the minstrel mac80211 rate control algorithm + CoDel delay detection to vary this high water mark. 2.1) Too much delay means that the high water mark is too high. 2.2) No delay at all means the water mark is too low. 2.3) HTB limit the upload speed to this water mark dynamically. What I want? I want an algorithm to try detecting the current available bandwidth on real time. Therefore, I could limit the upload speed as I would on my Tomato thus helping fq_codel does its work: reduce bufferbloat. We don't need optimal, we just need better than we currently have. :) Best regards, Mário Sérgio On 26/02/2013 19:25, Dave Taht wrote: > 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 > > 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" > 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 --------------090006060008000000060300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Here follows preliminary results using vanilla fq_codel by Eric Dumazet merged from Linux mainline. This was posted to the xda forum.

fq_codel+upload tests should yield results closer to the ones without an upload. fq_codel should both help maintain better latency than any other scheduling algorithm and work mostly without configuration. The upload speed rates should remain mostly unaffected by fq_codel.

The tests were conducted on a stock 4.2.2 maguro Galaxy Nexus with
latest AK 3.0.67+~ak.710.422.Cylon kernel. I did the tests between 01:00 and 03:00 local time (GMT-3).

root@android:/ # uname -a
Linux localhost 3.0.67+~ak.710.422.Cylon #1 SMP PREEMPT Wed Feb 27 06:54:36 CET 2013 armv7l GNU/Linux

Read the full post to gather an idea of what to expect. root access is required to perform these series of tests.

Here follows a simple upload + several ping/latency test guide. The ping tests are done against 187.7.117.32 (www DOT google DOT com).

1) Install the following applications from Play Store
 1.1) Fing
 1.2) Net Ping
 1.3) Network Latency Checker
 1.4) Terminal

2) Copy a huge file to your Galaxy Nexus. We will upload it later to create the upload test environment.

3) Connect your Galaxy Nexus to your WIFI network.

4) Make sure there is no other traffic on your network: no downloads, youtube, nothing.

5) Make sure fq_codel is not enabled.
 5.1) Open Terminal
 5.2) Type the following commands to make sure fq_codel is disabled

su
tc qdisc del dev wlan0 root fq_codel
tc -s qdisc
 
 5.3) You should get a result similar to the following. The wlan0 qdisc should read pfifo_fast.

root@android:/ # su
root@android:/ # tc qdisc del dev wlan0 root fq_codel
Android does not support qdisc 'fq_codel'
root@android:/ # tc -s qdisc
Android does not support qdisc 'prio'
qdisc pfifo_fast 0: dev rmnet0 root refcnt 2 [cannot parse qdisc parameters]
 Sent 2889806 bytes 15890 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
Android does not support qdisc 'prio'
qdisc pfifo_fast 0: dev p2p0 root refcnt 2 [cannot parse qdisc parameters]
 Sent 8892 bytes 114 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
Android does not support qdisc 'prio'
qdisc pfifo_fast 0: dev wlan0 root refcnt 2 [cannot parse qdisc parameters]
 Sent 25272 bytes 438 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
 
6) Let's stablish a baseline. We will conduct all tests without any traffic on your network. Furthermore, note that fq_codel is not enabled.

7) Start Fing
 7.1) Click Gear Icon
  7.1.1) Host Tools -> Ping -> 187.7.117.32
 7.2) Copy the results somewhere

8) Start Net Ping
 8.1) Settings
  8.1.1) Packet Count -> 100
  8.1.2) Statistics -> Enable
  8.1.3) Click Back
 8.2) Ping 187.7.117.32
 8.3) Copy the results somewhere

9) Start Network Latency Checker
 9.1) Select 100 request , 0s delay , DNS
 9.2) Click Check
 9.3) Copy the results somewhere
 9.4) Select 100 request , 0s delay , HTTP
 9.5) Click Check
 9.6) Copy the results somewhere

10) On your Galaxy Nexus, add the huge file from step 2 to your Google Drive. The upload will begin immediatly. If the upload finishes during any test, remove the file from Google Drive, upload it again then restart the given test.

11) Repeat Fing test
 11.1) Copy the results somewhere

12) Repeat Net Ping test
 12.1) Copy the results somewhere

13) Repeat Network Latency Checker test
 13.1) Copy the results somewhere

14) Enable fq_codel. If the upload finishes, remove the file from Google Drive and upload it again.
 14.1) Open Terminal
 14.2) Type the following commands to make sure fq_codel is disabled

su
tc qdisc add dev wlan0 root fq_codel
tc -s qdisc

 14.3) You should get a result similar to the following. The wlan0 qdisc should read fq_codel.

root@android:/ # su
root@android:/ # tc qdisc del dev wlan0 root fq_codel
Android does not support qdisc 'fq_codel'
root@android:/ # tc -s qdisc
Android does not support qdisc 'prio'
qdisc pfifo_fast 0: dev rmnet0 root refcnt 2 [cannot parse qdisc parameters]
 Sent 2889806 bytes 15890 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
Android does not support qdisc 'prio'
qdisc pfifo_fast 0: dev p2p0 root refcnt 2 [cannot parse qdisc parameters]
 Sent 8892 bytes 114 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
Android does not support qdisc 'fq_codel'
qdisc fq_codel 8001: dev wlan0 root refcnt 2 [cannot parse qdisc parameters]
 Sent 525997 bytes 6231 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
 
15) Repeat Fing test
 15.1) Copy the results somewhere

16) Repeat Net Ping test
 16.1) Copy the results somewhere

17) Repeat Network Latency Checker test
 17.1) Copy the results somewhere

-----
 
  For instance, here follows my personal results. The upload tests were conducted with a 150Mb upload to Google Drive as fast as my ADSL would allow it. My ADSL has an upload max speed rate of 512KiB.

1) Fing
 1.1) Results with neither upload nor fq_codel

64 average ping
6% package loss
60 minimum ping
112 maximum ping
0 std dev ping
5 estimated hops

 1.2) Results with upload but without fq_codel

226 average ping
2% package loss
68 minimum ping
580 maximum ping
2 std dev ping
5 estimated hops

 1.3) Results with both upload and fq_codel

180 average ping
6% package loss
67 minimum ping
510 maximum ping
3 std dev ping
5 estimated hops

2) Net Ping
 2.1) Results with neither upload nor fq_codel

187.7.117.32 min-max: 60.6-161ms
187.7.117.32 avg/stddev: 69.9/15.1ms

 2.2) Results with upload but without fq_codel

187.7.117.32 min-max: 69.6-510ms
187.7.117.32 avg/stddev: 251/110ms

 2.3) Results with both upload and fq_codel

187.7.117.32 min-max: 68.5-454ms
187.7.117.32 avg/stddev: 220/93.4ms

3) Network Latency Checker: 100 request , 0s delay , DNS
 3.1) Results with neither upload nor fq_codel

Min: 166 Max: 9338  Avg: 554

 3.2) Results with upload but without fq_codel

Min: 176 Max: 9306 Avg: 629

 3.3) Results with both upload and fq_codel

Min: 82 Max: 9649  Avg: 554

4) Network Latency Checker: 100 request , 0s delay , HTTP
 4.1) Results with neither upload nor fq_codel

Min: 260 Max: 3280 Avg: 342

 4.2) Results with upload but without fq_codel

Min: 239 Max: 10021 Avg: 1017

 4.3) Results with both upload and fq_codel

Min: 81 Max: 3477 Avg: 560

  The Network Latency Checker results present fq_codel as the best possible option on all cases. This was unexpected. I repeated those tests several times but fq_codel was always the best. I'll have to further review the Network Latency Checker tests. Can you reproduce these "weird" results?

  I can say that I am really satisfied with fq_codel on Android. It gave better performance than plain pfifo_fast with little extra cost.

  You can also try the exact same tests using 3G instead of WIFI. Replacing wlan0 with rmnet0 on the aforementioned steps should be enough. Check which interface is UP when you're using radio with the "netcfg" command on Terminal.

  I reached out to bufferbloat mailing list for suggestions on how to better test and tune the code for Android phones. :)

  Please, do not hesitate to suggest improvements or corrections to this post.

  One problem I have is that I "cannot" know beforehand what's the available upload bandwidth on the current radio connection (3G) so I cannot limit the upload to avoid intrinsic upload buffering as I would do with my home Tomato router.

  Something just occured to me. I apologize if it's stupid, naive or simply already exists: auto detect the available radio (2G/3G/4G) upload bandwidth .

  1) Inquiry the reported connection speed from the phone radio and use it as our high water mark.
  2) Use a variation of the minstrel mac80211 rate control algorithm + CoDel delay detection to vary this high water mark.
   2.1) Too much delay means that the high water mark is too high.
   2.2) No delay at all means the water mark is too low.
   2.3) HTB limit the upload speed to this water mark dynamically.

  What I want? I want an algorithm to try detecting the current available bandwidth on real time. Therefore, I could limit the upload speed as I would on my Tomato thus helping fq_codel does its work: reduce bufferbloat. We don't need optimal, we just need better than we currently have. :)

  Best regards,
    Mário Sérgio

On 26/02/2013 19:25, Dave Taht wrote:
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

--------------090006060008000000060300--