[Bloat] Testing fq_codel on Android Galaxy Nexus AK kernel
Mário Sérgio Fujikawa Ferreira
liouxbsd at gmail.com
Thu Feb 28 01:08:49 EST 2013
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 at 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 at android:/ # su
root at android:/ # tc qdisc del dev wlan0 root fq_codel
Android does not support qdisc 'fq_codel'
root at 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 at android:/ # su
root at android:/ # tc qdisc del dev wlan0 root fq_codel
Android does not support qdisc 'fq_codel'
root at 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 at gmail.com <mailto:chromatix99 at 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 at gmail.com
> <mailto:liouxbsd at 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 at lists.bufferbloat.net <mailto:Bloat at lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net <mailto:Bloat at lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat
>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20130228/907e9a30/attachment-0003.html>
More information about the Bloat
mailing list