From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 475AC20175A for ; Thu, 16 Jan 2014 15:15:43 -0800 (PST) Received: from hms-beagle-3.home.lan ([217.254.130.56]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MfVzj-1VgW6o03gZ-00P3gl for ; Fri, 17 Jan 2014 00:15:09 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 17 Jan 2014 00:15:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <957858c7-f436-47ec-a55f-d46c6441212a@email.android.com> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:eHTj3mAGbIdbpG0DqklTfyd8yvZsBbTAbJ9HCKxSwwc0SXnSqGZ xh5SyBLtEo+OIgtMhLh8YDug5D/GfseIHmKGWOgvEAUfICvWrn9zw64LVI1ZQQqw93fFTU3 3JitY8QrGJCmN908G9BeBH0vKRlZ8LTEqu9Bz2JpszqmM6vVS5TOeNUeLi0ewl8rcJxV0FA GMyRVUfeoAuKnoxav6Gtg== Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] Managed to break 802.11n (on a 3800) X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 23:15:48 -0000 Hi Dave, thanks again. On Jan 16, 2014, at 23:50 , Dave Taht wrote: >=20 >=20 >=20 > On Thu, Jan 16, 2014 at 3:10 PM, Sebastian Moeller = wrote: > Hi Aaron, >=20 >=20 > On Jan 16, 2014, at 20:08 , Aaron Wood wrote: >=20 >>=20 >>>> Sebastian, after sorting out the router, it's still biased, but far >>>> less >>>> so, about a 2:1 ratio between upload and download. >>>=20 >>> So I See offen 10:1 and worse @165Mbit/s raw wireless rate >>=20 >> I get mixed results, but they aren't good. =20 >=20 > It's hard to comment on each graph in email, but I'll try. >=20 > I generally run rrul with the --disable-log option. Log scales helped = back when we were still > comparing against pfifo fast. Good point, I had not thought about this and just sheepishly = copied the netperf-wrapper invocation from a scratch buffer=85. oops. >=20 > The really bad download graph. "Crazy results" >=20 > Download bandwith is bad because the upload starts and fills the queue = first, the download > has to wait to fill the queue and generally gets dropped earlier than = the upload. This is > one of the many reasons I don't care for IW10=85.=20 But aren't those two different queues? I am confused... >=20 > The upload gets better slowly due to how slow tcp is ramping up over = the half-duplex > wifi channel.=20 Yepp, my sentiment as well, the sharing between up and down = sucks badly. I naively assumed that cero would sort of manage TX-ops and = share these equally between its own sending needs and the remote = station=85 I guess wifi is too complicated (and I had thought last mile = wired connectivity was wonderfully weird...) >=20 >=20 > =20 >=20 > I just checked again and I get crazy results for both RRUL and = RRUL_NOCLASSIFICATION: > = >=20 > in both cases I get ~ 10:1 out-in imbalance. >=20 > I think that with a larger quantum on the AP they will be in less = imbalance, and you should try nfq_codel also. So for this I would modify the debloat script, correct? >=20 > The larger quantum will also hurt, too.... right answer has always = been per station queues. Which I will happily test once they are implemented :) >=20 > =20 > And even crazier just had one rrul where both in and out came up = almost perfectly at 1:1 Thinking of it again, it might have been a case of really really = low total bandwidth, so until this reoccurs I think it is a fluke... >=20 >=20 > Hmm. Wifi is weird, isn't it? It's not like ethernet at all. Too bad = the universe insists on trying to > defy the laws of physics by trying to make it act like ethernet=85. Oh, there was one new blurb last year about going full duplex on = wifi, which might help to make wiki behave closer to what people = nowadays correlate with ethernet... >=20 > =20 > . 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=85). >=20 > having 4 full queues and a txop each is far worse than 1 queue with = better aggregation, IMHO. So, the one queue would need to shave off all TOS (excuse my = occasional shouting, but all caps is the quickest way to avoid auto = correction turning my english even funnier), and have say HTB (or god = forbid prio) keep some semblance of priority on the packets instead of = letting wifi do its "let's waste a few tx ops" thing. Is it just me or = should wifi basically get a better tx-ops sheduler? > =20 > =20 > Note that measuring through cerowrt to a wired host (with too = restrictive firewall settings) get: > = >=20 > You are seeing the upload ramp up along tcp's lines and the download = ramp down as it gets progressively more starved. The sum seems constant, so yes. >=20 > =20 > with the MacBooks uplink still dominant (actually continually getting = more bandwidth=85). >=20 > Well, you only have X bandwidth, in the air, total. A better way of = saying it might be the macbook is taking better advantage > of it's txops to ship more data in an aggregate. Mmh, it looks like it gets more tx-ops or cero gets increasingly = bad in filling its tx-ops, no? >=20 > Since I my only wireless connected machines are macs and nobody else = complained about this issue I assume it is an osx issue >=20 > I honestly think that aside from benchmarks, bandwidth is irrelevant = on wifi. Lower latency is something that you > actually feel, and when accessing the web or doing a videoconference, = that's the part that matters. Oh, sure, and my quick and dirty real world test (bidirectional = data transfer initiated from the macbook turned out quite useable and = balanced). And I only see this on the local net were wireless is the = bottleneck. (Silly Idea, all I need to do is switch the wired machine to = 10Mbit ethernet and I will be fine :) ) >=20 > it IS possible to get the best of both worlds, but that's going to = take some driver rework. > =20 >=20 > > For comparison an RRUL test from the wired linux host to cerowrt, = where things look much better... >=20 >=20 >=20 >> 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) >=20 > 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=85) 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... >=20 >=20 > 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. And beating up it does ;) best regards Sebastian > =20 >>=20 >>=20 >>>> Also, my understanding was that with rts/cts, the router was in = control >>>> of >>>> that aspect of things? =20 >>>=20 >>> That is what I thought AS well, but it is not what I See with = osx 10.8. >>>=20 >>=20 >> 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. >=20 > I think we agree that the AP should show more self-confidence = and reject such requests more firmly :) >=20 >=20 >>=20 >> It should be clear in a monitor-mode tcpdump (or a statistical = summary of packets). >=20 > I am not really equipped to do this, with just one wireless = notebook at my disposal :) >=20 > best > Sebastian >=20 >=20 > Now that you have your laptops running this stuff (AWESOME thank you!) >=20 > If I can encourage you all to go outside, to like your nearest = cybercafe, or conference center, and run your rrul tests there... >=20 > ... you'll find out just how bad the rest of the world is... (and get = some good data). >=20 > 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.... >=20 >=20 >>=20 >> --Aaron >=20 >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html