<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Here follows preliminary results using
vanilla fq_codel by Eric Dumazet merged from Linux mainline. This
was posted to the xda forum.<br>
<br>
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.<br>
<br>
The tests were conducted on a stock 4.2.2 maguro Galaxy Nexus with
<br>
latest AK 3.0.67+~ak.710.422.Cylon kernel. I did the tests between
01:00 and 03:00 local time (GMT-3).<br>
<br>
root@android:/ # uname -a<br>
Linux localhost 3.0.67+~ak.710.422.Cylon #1 SMP PREEMPT Wed Feb 27
06:54:36 CET 2013 armv7l GNU/Linux<br>
<br>
Read the full post to gather an idea of what to expect. root
access is required to perform these series of tests.<br>
<br>
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). <br>
<br>
1) Install the following applications from Play Store<br>
1.1) Fing<br>
1.2) Net Ping<br>
1.3) Network Latency Checker<br>
1.4) Terminal<br>
<br>
2) Copy a huge file to your Galaxy Nexus. We will upload it later
to create the upload test environment.<br>
<br>
3) Connect your Galaxy Nexus to your WIFI network.<br>
<br>
4) Make sure there is no other traffic on your network: no
downloads, youtube, nothing.<br>
<br>
5) Make sure fq_codel is not enabled.<br>
5.1) Open Terminal<br>
5.2) Type the following commands to make sure fq_codel is
disabled<br>
<br>
su<br>
tc qdisc del dev wlan0 root fq_codel<br>
tc -s qdisc<br>
<br>
5.3) You should get a result similar to the following. The wlan0
qdisc should read pfifo_fast.<br>
<br>
root@android:/ # su<br>
root@android:/ # tc qdisc del dev wlan0 root fq_codel<br>
Android does not support qdisc 'fq_codel'<br>
root@android:/ # tc -s qdisc<br>
Android does not support qdisc 'prio'<br>
qdisc pfifo_fast 0: dev rmnet0 root refcnt 2 [cannot parse qdisc
parameters]<br>
Sent 2889806 bytes 15890 pkt (dropped 0, overlimits 0 requeues 0)<br>
backlog 0b 0p requeues 0<br>
Android does not support qdisc 'prio'<br>
qdisc pfifo_fast 0: dev p2p0 root refcnt 2 [cannot parse qdisc
parameters]<br>
Sent 8892 bytes 114 pkt (dropped 0, overlimits 0 requeues 0)<br>
backlog 0b 0p requeues 0<br>
Android does not support qdisc 'prio'<br>
qdisc pfifo_fast 0: dev wlan0 root refcnt 2 [cannot parse qdisc
parameters]<br>
Sent 25272 bytes 438 pkt (dropped 0, overlimits 0 requeues 0)<br>
backlog 0b 0p requeues 0<br>
<br>
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.<br>
<br>
7) Start Fing<br>
7.1) Click Gear Icon<br>
7.1.1) Host Tools -> Ping -> 187.7.117.32<br>
7.2) Copy the results somewhere<br>
<br>
8) Start Net Ping<br>
8.1) Settings<br>
8.1.1) Packet Count -> 100<br>
8.1.2) Statistics -> Enable<br>
8.1.3) Click Back<br>
8.2) Ping 187.7.117.32<br>
8.3) Copy the results somewhere<br>
<br>
9) Start Network Latency Checker<br>
9.1) Select 100 request , 0s delay , DNS<br>
9.2) Click Check<br>
9.3) Copy the results somewhere<br>
9.4) Select 100 request , 0s delay , HTTP<br>
9.5) Click Check<br>
9.6) Copy the results somewhere<br>
<br>
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.<br>
<br>
11) Repeat Fing test<br>
11.1) Copy the results somewhere<br>
<br>
12) Repeat Net Ping test<br>
12.1) Copy the results somewhere<br>
<br>
13) Repeat Network Latency Checker test<br>
13.1) Copy the results somewhere<br>
<br>
14) Enable fq_codel. If the upload finishes, remove the file from
Google Drive and upload it again.<br>
14.1) Open Terminal<br>
14.2) Type the following commands to make sure fq_codel is
disabled<br>
<br>
su<br>
tc qdisc add dev wlan0 root fq_codel<br>
tc -s qdisc<br>
<br>
14.3) You should get a result similar to the following. The wlan0
qdisc should read fq_codel.<br>
<br>
root@android:/ # su<br>
root@android:/ # tc qdisc del dev wlan0 root fq_codel<br>
Android does not support qdisc 'fq_codel'<br>
root@android:/ # tc -s qdisc<br>
Android does not support qdisc 'prio'<br>
qdisc pfifo_fast 0: dev rmnet0 root refcnt 2 [cannot parse qdisc
parameters]<br>
Sent 2889806 bytes 15890 pkt (dropped 0, overlimits 0 requeues 0)<br>
backlog 0b 0p requeues 0<br>
Android does not support qdisc 'prio'<br>
qdisc pfifo_fast 0: dev p2p0 root refcnt 2 [cannot parse qdisc
parameters]<br>
Sent 8892 bytes 114 pkt (dropped 0, overlimits 0 requeues 0)<br>
backlog 0b 0p requeues 0<br>
Android does not support qdisc 'fq_codel'<br>
qdisc fq_codel 8001: dev wlan0 root refcnt 2 [cannot parse qdisc
parameters]<br>
Sent 525997 bytes 6231 pkt (dropped 0, overlimits 0 requeues 0)<br>
backlog 0b 0p requeues 0<br>
<br>
15) Repeat Fing test<br>
15.1) Copy the results somewhere<br>
<br>
16) Repeat Net Ping test<br>
16.1) Copy the results somewhere<br>
<br>
17) Repeat Network Latency Checker test<br>
17.1) Copy the results somewhere <br>
<br>
-----<br>
<br>
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.<br>
<br>
1) Fing<br>
1.1) Results with neither upload nor fq_codel<br>
<br>
64 average ping<br>
6% package loss<br>
60 minimum ping<br>
112 maximum ping<br>
0 std dev ping<br>
5 estimated hops<br>
<br>
1.2) Results with upload but without fq_codel<br>
<br>
226 average ping<br>
2% package loss<br>
68 minimum ping<br>
580 maximum ping<br>
2 std dev ping<br>
5 estimated hops<br>
<br>
1.3) Results with both upload and fq_codel<br>
<br>
180 average ping<br>
6% package loss<br>
67 minimum ping<br>
510 maximum ping<br>
3 std dev ping<br>
5 estimated hops<br>
<br>
2) Net Ping<br>
2.1) Results with neither upload nor fq_codel<br>
<br>
187.7.117.32 min-max: 60.6-161ms<br>
187.7.117.32 avg/stddev: 69.9/15.1ms<br>
<br>
2.2) Results with upload but without fq_codel<br>
<br>
187.7.117.32 min-max: 69.6-510ms<br>
187.7.117.32 avg/stddev: 251/110ms<br>
<br>
2.3) Results with both upload and fq_codel<br>
<br>
187.7.117.32 min-max: 68.5-454ms<br>
187.7.117.32 avg/stddev: 220/93.4ms<br>
<br>
3) Network Latency Checker: 100 request , 0s delay , DNS<br>
3.1) Results with neither upload nor fq_codel<br>
<br>
Min: 166 Max: 9338 Avg: 554<br>
<br>
3.2) Results with upload but without fq_codel<br>
<br>
Min: 176 Max: 9306 Avg: 629 <br>
<br>
3.3) Results with both upload and fq_codel<br>
<br>
Min: 82 Max: 9649 Avg: 554<br>
<br>
4) Network Latency Checker: 100 request , 0s delay , HTTP<br>
4.1) Results with neither upload nor fq_codel<br>
<br>
Min: 260 Max: 3280 Avg: 342<br>
<br>
4.2) Results with upload but without fq_codel<br>
<br>
Min: 239 Max: 10021 Avg: 1017<br>
<br>
4.3) Results with both upload and fq_codel<br>
<br>
Min: 81 Max: 3477 Avg: 560<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
I reached out to bufferbloat mailing list for suggestions on how
to better test and tune the code for Android phones. :)<br>
<br>
Please, do not hesitate to suggest improvements or corrections
to this post.<br>
<br>
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.<br>
<br>
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 .<br>
<br>
1) Inquiry the reported connection speed from the phone radio
and use it as our high water mark.<br>
2) Use a variation of the minstrel mac80211 rate control
algorithm + CoDel delay detection to vary this high water mark.<br>
2.1) Too much delay means that the high water mark is too high.<br>
2.2) No delay at all means the water mark is too low.<br>
2.3) HTB limit the upload speed to this water mark dynamically.<br>
<br>
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. :)<br>
<br>
Best regards,<br>
Mário Sérgio<br>
<br>
On 26/02/2013 19:25, Dave Taht wrote:<br>
</div>
<blockquote
cite="mid:CAA93jw7jj6HVJo1Nn9twEx_dWof87tZ5116JXc6T_NNdx0b9_w@mail.gmail.com"
type="cite">Dear Mario:<br>
<br>
I read over the thread, don't have the energy to join the forum...
Please forward?<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
But: It might help a little and I'd love to know more.<br>
<br>
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.<br>
<br>
<a moz-do-not-send="true"
href="http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos">http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos</a><br>
<br>
<a moz-do-not-send="true" href="http://netseminar.stanford.edu/">http://netseminar.stanford.edu/</a><br>
<br>
<pre><a moz-do-not-send="true" rel="nofollow" href="http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be">http://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be</a></pre>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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....<br>
<div class="gmail_quote">On Tue, Feb 26, 2013 at 1:27 PM, Jonathan
Morton <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>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. </p>
<p>Tests involving heavy downlink traffic would measure bloat
at the cell tower, or at the ISP or access point for wifi
tests. </p>
<p> - Jonathan Morton<br>
</p>
<div class="gmail_quote">
<div>
<div class="h5">On Feb 26, 2013 7:58 PM, "Mario Ferreira"
<<a moz-do-not-send="true"
href="mailto:liouxbsd@gmail.com" target="_blank">liouxbsd@gmail.com</a>>
wrote:<br type="attribution">
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<p dir="ltr">Hi,</p>
<p dir="ltr"> After a small exchange, AK kernel
developer has added fq_codel to his Galaxy Nexus
kernel distribution.</p>
<p dir="ltr"><a moz-do-not-send="true"
href="http://forum.xda-developers.com/showthread.php?t=2163790"
target="_blank">http://forum.xda-developers.com/showthread.php?t=2163790</a></p>
<p dir="ltr"> Now, he would like to know how to
benchmark it to see the advantages. :)</p>
<p dir="ltr"> I know basic tests for desktop: mtr, <a
moz-do-not-send="true"
href="http://netalyzr.icsi.berkeley.edu"
target="_blank">netalyzr.icsi.berkeley.edu</a> and
download + browsing..</p>
<p dir="ltr"> What do you suggest for a wireless
only setup such as Android Phone?</p>
<p dir="ltr"> Best regards,<br>
Mário Sérgio</p>
<br>
</div>
</div>
_______________________________________________<br>
Bloat mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bloat@lists.bufferbloat.net"
target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/bloat"
target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
<br>
</blockquote>
</div>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a moz-do-not-send="true"
href="https://lists.bufferbloat.net/listinfo/bloat"
target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Dave Täht<br>
<br>
Fixing bufferbloat with cerowrt: <a moz-do-not-send="true"
href="http://www.teklibre.com/cerowrt/subscribe.html"
target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>
</blockquote>
<br>
<div style="bottom: auto; left: 231px; right: auto; top: 305px;
display: none;" class="translator-theme-default"
id="translator-floating-panel">
<div title="Click to translate"
id="translator-floating-panel-button"></div>
</div>
</body>
</html>