* [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel [not found] <CAH44Dxbt+fixeLHwmA7QnndhhUbAjUEORxAsfb5LarUD7a3ZMw@mail.gmail.com> @ 2013-02-26 17:40 ` Mario Ferreira 2013-02-26 18:27 ` Jonathan Morton 0 siblings, 1 reply; 8+ messages in thread From: Mario Ferreira @ 2013-02-26 17:40 UTC (permalink / raw) To: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel 2013-02-26 17:40 ` [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel Mario Ferreira @ 2013-02-26 18:27 ` Jonathan Morton 2013-02-26 18:48 ` Eric Dumazet 2013-02-26 22:25 ` Dave Taht 0 siblings, 2 replies; 8+ messages in thread From: Jonathan Morton @ 2013-02-26 18:27 UTC (permalink / raw) To: Mario Ferreira; +Cc: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel 2013-02-26 18:27 ` Jonathan Morton @ 2013-02-26 18:48 ` Eric Dumazet 2013-02-26 19:25 ` Simon Barber 2013-02-26 22:25 ` Dave Taht 1 sibling, 1 reply; 8+ messages in thread From: Eric Dumazet @ 2013-02-26 18:48 UTC (permalink / raw) To: Jonathan Morton; +Cc: bloat 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel 2013-02-26 18:48 ` Eric Dumazet @ 2013-02-26 19:25 ` Simon Barber 0 siblings, 0 replies; 8+ messages in thread From: Simon Barber @ 2013-02-26 19:25 UTC (permalink / raw) To: Eric Dumazet; +Cc: bloat 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel 2013-02-26 18:27 ` Jonathan Morton 2013-02-26 18:48 ` Eric Dumazet @ 2013-02-26 22:25 ` Dave Taht 2013-02-28 6:08 ` Mário Sérgio Fujikawa Ferreira 1 sibling, 1 reply; 8+ messages in thread From: Dave Taht @ 2013-02-26 22:25 UTC (permalink / raw) To: Jonathan Morton; +Cc: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel 2013-02-26 22:25 ` Dave Taht @ 2013-02-28 6:08 ` Mário Sérgio Fujikawa Ferreira 2013-03-10 1:21 ` Mário Sérgio Fujikawa Ferreira 0 siblings, 1 reply; 8+ messages in thread From: Mário Sérgio Fujikawa Ferreira @ 2013-02-28 6:08 UTC (permalink / raw) To: Dave Taht; +Cc: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel 2013-02-28 6:08 ` Mário Sérgio Fujikawa Ferreira @ 2013-03-10 1:21 ` Mário Sérgio Fujikawa Ferreira 2013-03-10 1:26 ` Mário Sérgio Fujikawa Ferreira 0 siblings, 1 reply; 8+ messages in thread From: Mário Sérgio Fujikawa Ferreira @ 2013-03-10 1:21 UTC (permalink / raw) To: Dave Taht; +Cc: bloat 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel 2013-03-10 1:21 ` Mário Sérgio Fujikawa Ferreira @ 2013-03-10 1:26 ` Mário Sérgio Fujikawa Ferreira 0 siblings, 0 replies; 8+ messages in thread From: Mário Sérgio Fujikawa Ferreira @ 2013-03-10 1:26 UTC (permalink / raw) To: Dave Taht; +Cc: bloat 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-03-10 1:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAH44Dxbt+fixeLHwmA7QnndhhUbAjUEORxAsfb5LarUD7a3ZMw@mail.gmail.com> 2013-02-26 17:40 ` [Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel Mario Ferreira 2013-02-26 18:27 ` Jonathan Morton 2013-02-26 18:48 ` Eric Dumazet 2013-02-26 19:25 ` Simon Barber 2013-02-26 22:25 ` Dave Taht 2013-02-28 6:08 ` Mário Sérgio Fujikawa Ferreira 2013-03-10 1:21 ` Mário Sérgio Fujikawa Ferreira 2013-03-10 1:26 ` Mário Sérgio Fujikawa Ferreira
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox