[Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel

[Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel

[Mario Ferreira]

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

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

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

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

[Jonathan Morton]

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

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
>
>

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

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

[Eric Dumazet]

On Tue, 2013-02-26 at 20:27 +0200, 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. 

I have serious doubts this will show something.

I guess the queue of not yet sent packets will be _after_ qdisc layer,
in the network device itself.

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

[Simon Barber]

What is the interface to these 3G modems? Is there a 'packet has been 
transmitted' ACK that could be used to implement a BQL (or better still 
- time queue limit)?

Simon

On Tue 26 Feb 2013 10:48:33 AM PST, Eric Dumazet wrote:
> On Tue, 2013-02-26 at 20:27 +0200, 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.
>
> I have serious doubts this will show something.
>
> I guess the queue of not yet sent packets will be _after_ qdisc layer,
> in the network device itself.
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

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

[Dave Taht]

[-- 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 --]

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

[Mário Sérgio Fujikawa Ferreira]

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

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 <mailto: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
>     <mailto: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 <http://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 <mailto:Bloat@lists.bufferbloat.net>
>         https://lists.bufferbloat.net/listinfo/bloat
>
>
>     _______________________________________________
>     Bloat mailing list
>     Bloat@lists.bufferbloat.net <mailto: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: 19253 bytes --]

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

[Mário Sérgio Fujikawa Ferreira]

   Further information gathering. I won't procced with any further 
testing. I am neither sure how to interpret the data I already have for 
wlan0 nor that I am using the proper tools for the job.

   I look forward to your input. I would like to be able to gather good 
values for both quantum and limit. I want to set them appropriately for 
the radio and wifi connections. Since we don't have the properly patched 
tc command, I'll probably be hard coding this on the fq_codel module itself.

   Are there recommendations? If a guideline is available/suggested, 
I'll try to find good average values for this particular phone.

   The data I gathered currently follows:

- Android phone Samsung Galaxy Nexus GSM I9250 running stock Yakju 4.2.2 
with AK kernel
- WIFI connected to LAN, ADSL 512KiB U, Phone Google Drive upload at 
full speed. No other traffic on the network
- The drivers are available in binary form from 
https://developers.google.com/android/nexus/drivers
- Quick look on the Galaxy Nexus 
http://wiki.rootzwiki.com/Samsung_Galaxy_Nexus
- There is a teardown of all components on 
http://www.ifixit.com/Teardown/Samsung+Galaxy+Nexus+Teardown/7182/1
     - Radio: Intel XG626 Baseband Modem
     - WiFi / Bluetooth module: Broadcom BCM4330
         - Samsung SWB-B42 BT 4.0 Dual Band Wlan FM Tx/Rx. Chipworks 
says the module is actually manufactured by Murata, and houses a 
Broadcom BCM4330 die inside.

# 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
# netcfg
lo       UP                                   127.0.0.1/8 0x00000049
ifb0     DOWN                                   0.0.0.0/0 0x00000082
ifb1     DOWN                                   0.0.0.0/0 0x00000082
tunl0    DOWN                                   0.0.0.0/0 0x00000080
sit0     DOWN                                   0.0.0.0/0 0x00000080
ip6tnl0  DOWN                                   0.0.0.0/0 0x00000080
rmnet0   DOWN                                   0.0.0.0/0 0x00001090
rmnet1   DOWN                                   0.0.0.0/0 0x00001090
rmnet2   DOWN                                   0.0.0.0/0 0x00001090
p2p0     UP                                     0.0.0.0/0 0x00001003
wlan0    UP                                  10.0.0.101/25 0x00001043
# ls -l /sys/class/net/p2p0/
-r--r--r-- root     root         4096 2013-03-02 21:33 addr_assign_type
-r--r--r-- root     root         4096 2013-03-02 21:33 addr_len
-r--r--r-- root     root         4096 2013-03-02 21:33 address
-r--r--r-- root     root         4096 2013-03-02 21:33 broadcast
-r--r--r-- root     root         4096 2013-03-02 21:33 carrier
-r--r--r-- root     root         4096 2013-03-02 21:33 dev_id
lrwxrwxrwx root     root              2013-03-02 21:33 device -> 
../../../mmc1:0001:2
-r--r--r-- root     root         4096 2013-03-02 21:33 dormant
-r--r--r-- root     root         4096 2013-03-02 21:33 duplex
-r--r--r-- root     root         4096 2013-03-02 21:33 features
-rw-r--r-- root     root         4096 2013-03-02 21:33 flags
-rw-r--r-- root     root         4096 2013-03-02 21:33 ifalias
-r--r--r-- root     root         4096 2013-03-02 21:33 ifindex
-r--r--r-- root     root         4096 2013-03-02 21:33 iflink
-r--r--r-- root     root         4096 2013-03-02 21:33 link_mode
-rw-r--r-- root     root         4096 2013-03-02 21:33 mtu
-rw-r--r-- root     root         4096 2013-03-02 21:33 netdev_group
-r--r--r-- root     root         4096 2013-03-02 21:33 operstate
lrwxrwxrwx root     root              2013-03-02 21:33 phy80211 -> 
../../ieee80211/phy0
drwxr-xr-x root     root              2013-03-02 21:33 power
drwxr-xr-x root     root              2013-03-02 21:33 queues
-r--r--r-- root     root         4096 2013-03-02 21:33 speed
drwxr-xr-x root     root              2013-03-02 21:33 statistics
lrwxrwxrwx root     root              2013-03-02 21:33 subsystem -> 
../../../../../../../../../../class/net
-rw-r--r-- root     root         4096 2013-03-02 21:33 tx_queue_len
-r--r--r-- root     root         4096 2013-03-02 21:33 type
-rw-r--r-- root     root         4096 2013-03-02 21:33 uevent

# ls -l /sys/class/net/wlan0/
-r--r--r-- root     root         4096 2013-03-02 21:38 addr_assign_type
-r--r--r-- root     root         4096 2013-03-02 21:38 addr_len
-r--r--r-- root     root         4096 2013-03-02 21:38 address
-r--r--r-- root     root         4096 2013-03-02 21:38 broadcast
-r--r--r-- root     root         4096 2013-03-02 21:38 carrier
-r--r--r-- root     root         4096 2013-03-02 21:38 dev_id
lrwxrwxrwx root     root              2013-03-02 21:38 device -> 
../../../mmc1:0
001:2
-r--r--r-- root     root         4096 2013-03-02 21:38 dormant
-r--r--r-- root     root         4096 2013-03-02 21:38 duplex
-r--r--r-- root     root         4096 2013-03-02 21:38 features
-rw-r--r-- root     root         4096 2013-03-02 21:38 flags
-rw-r--r-- root     root         4096 2013-03-02 21:38 ifalias
-r--r--r-- root     root         4096 2013-03-02 21:38 ifindex
-r--r--r-- root     root         4096 2013-03-02 21:38 iflink
-r--r--r-- root     root         4096 2013-03-02 21:38 link_mode
-rw-r--r-- root     root         4096 2013-03-02 21:38 mtu
-rw-r--r-- root     root         4096 2013-03-02 21:38 netdev_group
-r--r--r-- root     root         4096 2013-03-02 21:38 operstate
lrwxrwxrwx root     root              2013-03-02 21:38 phy80211 -> 
../../ieee80211/phy0
drwxr-xr-x root     root              2013-03-02 21:38 power
drwxr-xr-x root     root              2013-03-02 21:38 queues
-r--r--r-- root     root         4096 2013-03-02 21:38 speed
drwxr-xr-x root     root              2013-03-02 21:31 statistics
lrwxrwxrwx root     root              2013-03-02 21:38 subsystem -> 
../../../../../../../../../../class/net
-rw-r--r-- root     root         4096 2013-03-02 21:38 tx_queue_len
-r--r--r-- root     root         4096 2013-03-02 21:38 type
-rw-r--r-- root     root         4096 2013-03-02 21:38 uevent

   By quick traffic examination, it seems that all WIFI traffic flows 
through wlan0:

# tc -s qdisc
Android does not support qdisc 'fq_codel'
qdisc fq_codel 8001: dev rmnet0 root refcnt 2 [cannot parse qdisc 
parameters]
  Sent 0 bytes 0 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 468 bytes 6 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 38442999 bytes 26737 pkt (dropped 0, overlimits 0 requeues 0)
  backlog 0b 0p requeues 0

   Here follows the information on wlan0 interface:

# cat /sys/class/net/wlan0/tx_queue_len
1000
# cat /sys/class/net/wlan0/speed
sh: cat: /sys/class/net/wlan0/speed: Invalid argument
# ls -l /sys/class/net/wlan0/queues
drwxr-xr-x root     root              2013-03-02 22:04 rx-0
drwxr-xr-x root     root              2013-03-02 22:04 tx-0
# ls -l /sys/class/net/wlan0/queues/tx-0
-rw-r--r-- root     root         4096 2013-03-02 22:04 xps_cpus

   Tests follow in the next email.

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

[Mário Sérgio Fujikawa Ferreira]

On 09/03/2013 22:21, Mário Sérgio Fujikawa Ferreira wrote:
> Further information gathering. I won't procced with any further 
> testing. I am neither sure how to interpret the data I already have 
> for wlan0 nor that I am using the proper tools for the job.
>
>   I look forward to your input. I would like to be able to gather good 
> values for both quantum and limit. I want to set them appropriately 
> for the radio and wifi connections. Since we don't have the properly 
> patched tc command, I'll probably be hard coding this on the fq_codel 
> module itself.
>
>   Are there recommendations? If a guideline is available/suggested, 
> I'll try to find good average values for this particular phone.
>
>   The data I gathered currently follows:
>
> - Android phone Samsung Galaxy Nexus GSM I9250 running stock Yakju 
> 4.2.2 with AK kernel
> - WIFI connected to LAN, ADSL 512KiB U, Phone Google Drive upload at 
> full speed. No other traffic on the network
> - The drivers are available in binary form from 
> https://developers.google.com/android/nexus/drivers
> - Quick look on the Galaxy Nexus 
> http://wiki.rootzwiki.com/Samsung_Galaxy_Nexus
> - There is a teardown of all components on 
> http://www.ifixit.com/Teardown/Samsung+Galaxy+Nexus+Teardown/7182/1
>     - Radio: Intel XG626 Baseband Modem
>     - WiFi / Bluetooth module: Broadcom BCM4330
>         - Samsung SWB-B42 BT 4.0 Dual Band Wlan FM Tx/Rx. Chipworks 
> says the module is actually manufactured by Murata, and houses a 
> Broadcom BCM4330 die inside.
>
> # 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
> # netcfg
> lo       UP                                   127.0.0.1/8 0x00000049
> ifb0     DOWN                                   0.0.0.0/0 0x00000082
> ifb1     DOWN                                   0.0.0.0/0 0x00000082
> tunl0    DOWN                                   0.0.0.0/0 0x00000080
> sit0     DOWN                                   0.0.0.0/0 0x00000080
> ip6tnl0  DOWN                                   0.0.0.0/0 0x00000080
> rmnet0   DOWN                                   0.0.0.0/0 0x00001090
> rmnet1   DOWN                                   0.0.0.0/0 0x00001090
> rmnet2   DOWN                                   0.0.0.0/0 0x00001090
> p2p0     UP                                     0.0.0.0/0 0x00001003
> wlan0    UP                                  10.0.0.101/25 0x00001043
> # ls -l /sys/class/net/p2p0/
> -r--r--r-- root     root         4096 2013-03-02 21:33 addr_assign_type
> -r--r--r-- root     root         4096 2013-03-02 21:33 addr_len
> -r--r--r-- root     root         4096 2013-03-02 21:33 address
> -r--r--r-- root     root         4096 2013-03-02 21:33 broadcast
> -r--r--r-- root     root         4096 2013-03-02 21:33 carrier
> -r--r--r-- root     root         4096 2013-03-02 21:33 dev_id
> lrwxrwxrwx root     root              2013-03-02 21:33 device -> 
> ../../../mmc1:0001:2
> -r--r--r-- root     root         4096 2013-03-02 21:33 dormant
> -r--r--r-- root     root         4096 2013-03-02 21:33 duplex
> -r--r--r-- root     root         4096 2013-03-02 21:33 features
> -rw-r--r-- root     root         4096 2013-03-02 21:33 flags
> -rw-r--r-- root     root         4096 2013-03-02 21:33 ifalias
> -r--r--r-- root     root         4096 2013-03-02 21:33 ifindex
> -r--r--r-- root     root         4096 2013-03-02 21:33 iflink
> -r--r--r-- root     root         4096 2013-03-02 21:33 link_mode
> -rw-r--r-- root     root         4096 2013-03-02 21:33 mtu
> -rw-r--r-- root     root         4096 2013-03-02 21:33 netdev_group
> -r--r--r-- root     root         4096 2013-03-02 21:33 operstate
> lrwxrwxrwx root     root              2013-03-02 21:33 phy80211 -> 
> ../../ieee80211/phy0
> drwxr-xr-x root     root              2013-03-02 21:33 power
> drwxr-xr-x root     root              2013-03-02 21:33 queues
> -r--r--r-- root     root         4096 2013-03-02 21:33 speed
> drwxr-xr-x root     root              2013-03-02 21:33 statistics
> lrwxrwxrwx root     root              2013-03-02 21:33 subsystem -> 
> ../../../../../../../../../../class/net
> -rw-r--r-- root     root         4096 2013-03-02 21:33 tx_queue_len
> -r--r--r-- root     root         4096 2013-03-02 21:33 type
> -rw-r--r-- root     root         4096 2013-03-02 21:33 uevent
>
> # ls -l /sys/class/net/wlan0/
> -r--r--r-- root     root         4096 2013-03-02 21:38 addr_assign_type
> -r--r--r-- root     root         4096 2013-03-02 21:38 addr_len
> -r--r--r-- root     root         4096 2013-03-02 21:38 address
> -r--r--r-- root     root         4096 2013-03-02 21:38 broadcast
> -r--r--r-- root     root         4096 2013-03-02 21:38 carrier
> -r--r--r-- root     root         4096 2013-03-02 21:38 dev_id
> lrwxrwxrwx root     root              2013-03-02 21:38 device -> 
> ../../../mmc1:0
> 001:2
> -r--r--r-- root     root         4096 2013-03-02 21:38 dormant
> -r--r--r-- root     root         4096 2013-03-02 21:38 duplex
> -r--r--r-- root     root         4096 2013-03-02 21:38 features
> -rw-r--r-- root     root         4096 2013-03-02 21:38 flags
> -rw-r--r-- root     root         4096 2013-03-02 21:38 ifalias
> -r--r--r-- root     root         4096 2013-03-02 21:38 ifindex
> -r--r--r-- root     root         4096 2013-03-02 21:38 iflink
> -r--r--r-- root     root         4096 2013-03-02 21:38 link_mode
> -rw-r--r-- root     root         4096 2013-03-02 21:38 mtu
> -rw-r--r-- root     root         4096 2013-03-02 21:38 netdev_group
> -r--r--r-- root     root         4096 2013-03-02 21:38 operstate
> lrwxrwxrwx root     root              2013-03-02 21:38 phy80211 -> 
> ../../ieee80211/phy0
> drwxr-xr-x root     root              2013-03-02 21:38 power
> drwxr-xr-x root     root              2013-03-02 21:38 queues
> -r--r--r-- root     root         4096 2013-03-02 21:38 speed
> drwxr-xr-x root     root              2013-03-02 21:31 statistics
> lrwxrwxrwx root     root              2013-03-02 21:38 subsystem -> 
> ../../../../../../../../../../class/net
> -rw-r--r-- root     root         4096 2013-03-02 21:38 tx_queue_len
> -r--r--r-- root     root         4096 2013-03-02 21:38 type
> -rw-r--r-- root     root         4096 2013-03-02 21:38 uevent
>
>   By quick traffic examination, it seems that all WIFI traffic flows 
> through wlan0:
>
> # tc -s qdisc
> Android does not support qdisc 'fq_codel'
> qdisc fq_codel 8001: dev rmnet0 root refcnt 2 [cannot parse qdisc 
> parameters]
>  Sent 0 bytes 0 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 468 bytes 6 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 38442999 bytes 26737 pkt (dropped 0, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>
>   Here follows the information on wlan0 interface:
>
> # cat /sys/class/net/wlan0/tx_queue_len
> 1000
> # cat /sys/class/net/wlan0/speed
> sh: cat: /sys/class/net/wlan0/speed: Invalid argument
> # ls -l /sys/class/net/wlan0/queues
> drwxr-xr-x root     root              2013-03-02 22:04 rx-0
> drwxr-xr-x root     root              2013-03-02 22:04 tx-0
> # ls -l /sys/class/net/wlan0/queues/tx-0
> -rw-r--r-- root     root         4096 2013-03-02 22:04 xps_cpus
>
>   Tests follow in the next email.

   Let's try to measure the hardware buffer by sending 500 pings to 
187.7.117.32 with "Net Ping" from Play Store. I'll use different 
txqueuelen values each time. There is a concurrent upload at full speed 
to Google Drive.

# echo 0 > /sys/class/net/wlan0/tx_queue_len
# cat /sys/class/net/wlan0/tx_queue_len
0

500 pings
(187.7.117.32) min-max: 61.6-1058 ms
(187.7.117.32) avg/stddev: 315/167 ms

# echo 1 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 60.3-1365 ms
(187.7.117.32) avg/stddev: 602/310 ms

# echo 10 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 61.2-1337  ms
(187.7.117.32) avg/stddev: 571/288 ms

# echo 100 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 61.2-1455  ms
(187.7.117.32) avg/stddev: 647/343 ms

# echo 1000 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 60.0-1484  ms
(187.7.117.32) avg/stddev: 616/342 ms

     Repeat the above tests without the concurrent upload.

# echo 0 > /sys/class/net/wlan0/tx_queue_len
# echo 0 > /sys/class/net/p2p0/tx_queue_len

500 pings
(187.7.117.32) min-max: 61.7-213 ms
(187.7.117.32) avg/stddev: 70.6/15.0 ms

# echo 1 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 60.7-207 ms
(187.7.117.32) avg/stddev: 70.5/15.4 ms

# echo 10 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 60.6-244  ms
(187.7.117.32) avg/stddev: 69.1/10.5 ms

# echo 100 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 60.7-246  ms
(187.7.117.32) avg/stddev: 70.1/15.4 ms

# echo 1000 > /sys/class/net/wlan0/tx_queue_len

500 pings
(187.7.117.32) min-max: 61.4-251  ms
(187.7.117.32) avg/stddev: 70.2/16.3 ms

   I've disabled WIFI and enabled 3G. I've got a HDSPA connection.

# netcfg
lo       UP                                   127.0.0.1/8 0x00000049
00:00:00
ifb0     DOWN                                   0.0.0.0/0 0x00000082
f9:64:69
ifb1     DOWN                                   0.0.0.0/0 0x00000082
c6:b4:f9
tunl0    DOWN                                   0.0.0.0/0 0x00000080
00:00:00
sit0     DOWN                                   0.0.0.0/0 0x00000080
00:00:00
ip6tnl0  DOWN                                   0.0.0.0/0 0x00000080
00:00:00
rmnet0   UP                              179.225.225.71/24 0x000010d1
00:00:00
rmnet1   DOWN                                   0.0.0.0/0 0x00001090
00:00:00
rmnet2   DOWN                                   0.0.0.0/0 0x00001090
00:00:00
p2p0     DOWN                                   0.0.0.0/0 0x00001002
c5:c2:4e
wlan0    DOWN                                   0.0.0.0/0 0x00001002

   Here follows the information on rmnet0 interface:

# cat /sys/class/net/rmnet0/tx_queue_len
1000
# cat /sys/class/net/rmnet0/speed
/system/bin/sh: cat: /sys/class/net/rmnet0/speed: Invalid argument
# ls -l /sys/class/net/rmnet0/queues
drwxr-xr-x root     root              2013-03-03 15:03 rx-0
drwxr-xr-x root     root              2013-03-03 15:03 tx-0
# ls -l /sys/class/net/rmnet0/queues/tx-0
-rw-r--r-- root     root         4096 2013-03-03 15:03 xps_cpus

   I will await for your orientation before doing any other testing. 
I've submitted patches to change the default fq_codel limit from 10*1024 
to 600 which seem to be reasonable for cel radio/wifi speeds according to:

http://www.bufferbloat.net/projects/codel/wiki/Best_Practices_for_Benchmarking_CoDel_and_FQ_CoDel

   Also, I'm pushing for the addition of TCP Small Queues. What default 
value do you suggest we use there? The default is 131032. Should I use a 
small default?

   Best regards,
     Mário Sérgio