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