<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 3:10 PM, Sebastian Moeller <span dir="ltr"><<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Aaron,<div><br></div><div><br><div><div class="im"><div>On Jan 16, 2014, at 20:08 , Aaron Wood <<a href="mailto:woody77@gmail.com" target="_blank">woody77@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><br><blockquote type="cite"><blockquote type="cite">Sebastian, after sorting out the router, it's still biased, but far<br>less<br>so, about a 2:1 ratio between upload and download.<br></blockquote>
<br>So I See offen 10:1 and worse @165Mbit/s raw wireless rate<br></blockquote><br>I get mixed results, but they aren't good.  </blockquote></div></div></div></div></blockquote><div><br></div><div>It's hard to comment on each graph in email, but I'll try.<br>
<br></div><div>I generally run rrul with the --disable-log option. Log scales helped back when we were still<br>comparing against pfifo fast.<br><br></div><div>The really bad download graph. "Crazy results"<br><br>
</div><div>Download bandwith is bad because the upload starts and fills the queue first, the download<br></div><div>has to wait to fill the queue and generally gets dropped earlier than the upload. This is<br>one of the many reasons I don't care for IW10.... <br>
<br>The upload gets better slowly due to how slow tcp is ramping up over the half-duplex<br>wifi channel. <br></div><div><br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div class="im"><div><br></div></div><div><span style="white-space:pre-wrap">     </span>I just checked again and I get crazy results for both RRUL and RRUL_NOCLASSIFICATION:</div><div>
<img src="cid:92E1A0F2-BD4C-45B0-8BAD-2D04EE115BA4@home.lan" height="368" width="640"><img src="cid:A2FCA964-5252-4595-838E-F7DB193A4ECC@home.lan" height="368" width="640"></div><div><br></div><div>in both cases I get ~ 10:1 out-in imbalance. </div>
</div></div></div></blockquote><div><br></div><div>I think that with a larger quantum on the AP they will be in less imbalance, and you should try nfq_codel also.<br><br></div><div>The larger quantum will also hurt, too.... right answer has always been per station queues.<br>
<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>And even crazier just had one rrul where both in and out came up almost perfectly at 1:1</div>
</div></div></div></blockquote><div><br></div><br></div><div class="gmail_quote">Hmm. Wifi is weird, isn't it? It's not like ethernet at all. Too bad the universe insists on trying to<br>defy the laws of physics by trying to make it act like ethernet....<br>
<br></div><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>. Interestingly the classification really works in giving different bandwidth for the different classes. (And in rrul_noclassification, where the still classified UDP probes make it through the EF flow gets shorter latencies…).</div>
</div></div></div></blockquote><div><br></div><div>having 4 full queues and a txop each is far worse than 1 queue with better aggregation, IMHO.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div> </div><div><span style="white-space:pre-wrap">  </span>Note that measuring through cerowrt to a wired host (with too restrictive firewall settings) get:</div><div><img src="cid:7DD7D099-E8C3-47EF-B7A4-3B1C704E57B1@home.lan" height="368" width="640"><img src="cid:2EAAABFA-B386-499E-B47B-566A6E798DBF@home.lan" height="368" width="640"></div>
<div></div></div></div></div></blockquote><div><br></div><div>You are seeing the upload ramp up along tcp's lines and the download ramp down as it gets progressively more starved.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div>with the MacBooks uplink still dominant (actually continually getting more bandwidth…). </div></div></div></div></blockquote><div><br></div><div>Well, you only have X bandwidth, in the air, total. A better way of saying it might be the macbook is taking better advantage<br>
of it's txops to ship more data in an aggregate.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>Since I my only wireless connected machines are macs and nobody else complained about this issue I assume it is an osx issue</div>
</div></div></div></blockquote><div><br></div><div>I honestly think that aside from benchmarks, bandwidth is irrelevant on wifi. Lower latency is something that you<br>actually feel, and when accessing the web or doing a videoconference, that's the part that matters.<br>
<br></div><div>it IS possible to get the best of both worlds, but that's going to take some driver rework.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div><br></div><div><img src="cid:78BF6C9A-007D-47B8-BF4D-C6C8CF6BA2AA@home.lan" height="480" width="572"></div><div>For comparison an RRUL test from the wired linux host to cerowrt, where things look much better...</div>
<div class="im"><div><br></div><div><br></div><br><blockquote type="cite">IIRC, apple really changed something about the media access in 10.8, I'll look into that.  And see if my wife will let me install netperf on her laptop (I think it's still running 10.7)<br>
</blockquote><div><br></div></div><div><span style="white-space:pre-wrap">  </span>Yeah, good question whether this is the same in all macosx versions? (Sonner or later I will switch to 10.9 and repeat the measurements…) The saving grace is that I usually either upload or download at home between my 2 computers so I rarely feel the full force of this unfortunate macosx behavior. Just checked using SMB to copy a file to the wired machine and from the wired machine at the same time, nicely splits the bandwidth evenly between up and download, so this might be netsurf related...</div>
<div class="im"><br></div></div></div></div></blockquote><div><br></div><div>Single threaded tests will generally work ok, which is why nobody before has complained... which is why rrul exists to beat up things like torrent-like ,web like videoconferencing-like and voip-like behaviors.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="im"><blockquote type="cite"><br><br><blockquote type="cite">
<blockquote type="cite">Also, my understanding was that with rts/cts, the router was in control<br>of<br>that aspect of things?  <br></blockquote><br>     That is what I thought AS well, but it is not what I See with osx 10.8.<br>
<br></blockquote><br>It may be a case of the station aggressively asking to send, and the AP granting instead of sending data to the station that's waiting.<br></blockquote><div><br></div></div><div><span style="white-space:pre-wrap">      </span>I think we agree that the AP should show more self-confidence and reject such requests more firmly :)</div>
<div class="im"><div><br></div><br><blockquote type="cite"><br>It should be clear in a monitor-mode tcpdump (or a statistical summary of packets).</blockquote><div><br></div></div><div><span style="white-space:pre-wrap">  </span>I am not really equipped to do this, with just one wireless notebook at my disposal :)</div>
<div><br></div><div>best</div><div><span style="white-space:pre-wrap">      </span>Sebastian</div><div><br></div></div></div></div></blockquote><div><br></div><div>Now that you have your laptops running this stuff (AWESOME thank you!)<br>
<br></div><div>If I can encourage you all to go outside, to like your nearest cybercafe, or conference center, and run your rrul tests there...<br><br></div><div>... you'll find out just how bad the rest of the world is... (and get some good data).<br>
<br></div><div>I routinely see 4-6 seconds of latency, and a bare megabit or two of actual bandwidth. The ONLY place Iv'e ever had decent wifi performance in a busy area has been at ietf conferences....<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div></div><br><blockquote type="cite"><br>--Aaron</blockquote></div><br></div></div><br>_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a> 
</div></div>