From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D59B421F13F for ; Thu, 16 Jan 2014 15:40:10 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id x13so3803112wgg.21 for ; Thu, 16 Jan 2014 15:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qd07iqIWuquu9LiTkMC5z7UxHaCLMAvC1gWTFwcD93M=; b=C7DqGJ123RTJ14kYZsf1aNUBbMeZzL+BXMyGOK2w1gan+xd6AOguBo1+BNuV5g+QUk 3XbupU2P63w88EN0Xkmt7LpkiZLeWvbGsnz5nJRUmjzgEzj4IwR3CoW8aj03dfcxK1WP XwW7OtWSuJLJ6uiU1VSFXd3c8/MVnCGgsAWp9cCiYaEs86UJoVmeYWfN+gvFQYps1k8T b89m+BjBmpSaGhfw8/OnZ/l+2n4z6WDlCfYwBfmhV0aXSasy8XPjjfQ1pw0CsW3E5K+j FgE7/fk2Vth06Siof9TS6cVJHl8nkKrZMAkK36ttyoiteoOSt5jpoM+XQp0PB9TtTNG9 f8uA== MIME-Version: 1.0 X-Received: by 10.194.75.198 with SMTP id e6mr10799932wjw.3.1389915608719; Thu, 16 Jan 2014 15:40:08 -0800 (PST) Received: by 10.217.123.69 with HTTP; Thu, 16 Jan 2014 15:40:08 -0800 (PST) In-Reply-To: References: <957858c7-f436-47ec-a55f-d46c6441212a@email.android.com> Date: Thu, 16 Jan 2014 18:40:08 -0500 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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:40:11 -0000 On Thu, Jan 16, 2014 at 6:15 PM, Sebastian Moeller wrote: > Hi Dave, > > thanks again. > > On Jan 16, 2014, at 23:50 , Dave Taht wrote: > >> >> >> >> On Thu, Jan 16, 2014 at 3:10 PM, Sebastian Moeller wro= te: >> Hi Aaron, >> >> >> On Jan 16, 2014, at 20:08 , Aaron Wood wrote: >> >>> >>>>> Sebastian, after sorting out the router, it's still biased, but far >>>>> less >>>>> so, about a 2:1 ratio between upload and download. >>>> >>>> So I See offen 10:1 and worse @165Mbit/s raw wireless rate >>> >>> I get mixed results, but they aren't good. >> >> It's hard to comment on each graph in email, but I'll try. >> >> I generally run rrul with the --disable-log option. Log scales helped ba= ck when we were still >> comparing against pfifo fast. > > Good point, I had not thought about this and just sheepishly copi= ed the netperf-wrapper invocation from a scratch buffer=85. oops. I think --disable-log should be the default... except that for everyone not running an AQM the results they will get will need log scales... > >> >> The really bad download graph. "Crazy results" >> >> Download bandwith is bad because the upload starts and fills the queue f= irst, the download >> has to wait to fill the queue and generally gets dropped earlier than th= e upload. This is >> one of the many reasons I don't care for IW10=85. > > But aren't those two different queues? I am confused... One flow using TCP is sending 66 byte acks at the same time another flow is sending full 1500 byte packets. so if you have "2" TCP flows, you actually have 4 flows, 2 in each direction, one with big packets, the other with little. So what is happening in the fq_codel case with a 300 byte quantum is you will see (flows 1 and 3 are down, 2 and 4 are data up), roughly, in a packet capture, is something like this: FLOW ACK DATA 1 1 1 1 1 1 1 1 2 1 3 1 3 1 3 1 3 1 4 1 1 1 1 1 1 1 1 1 3 1 3 1 3 1 3 1 1 1 1 1 1 1 1 1 3 1 3 1 3 1 3 1 (repeat til you've served up 1500 bytes from each small flow, then deliver the 1500 byte packet) It's more complicated than this as you typically ack only every other packe= t... nfq_codel is different in that it rotates the flow queue on every packet much like SFQ does, but still pays attention to the quantum 1 1 2 1 3 1 4 1 1 1 3 1 1 1 3 1 1 1 1 1 # serve up 1500 bytes of acks 2 1 4 1 SFQ would look like this 1 1 2 1 3 1 4 1 1 1 2 1 3 1 4 1 I've long meant to port over the sfq_codel implementation from ns2 but have= n't got round to it. >> The upload gets better slowly due to how slow tcp is ramping up over the= half-duplex >> wifi channel. > > 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 t= hese equally between its own sending needs and the remote station=85 I gues= s wifi is too complicated (and I had thought last mile wired connectivity w= as wonderfully weird...) One day... I view most of the problems modern-day wifi has as solvable... and critical to society that we fix them. > >> >> >> >> >> I just checked again and I get crazy results for both RRUL and RRU= L_NOCLASSIFICATION: >> >> >> in both cases I get ~ 10:1 out-in imbalance. >> >> I think that with a larger quantum on the AP they will be in less imbala= nce, and you should try nfq_codel also. > > So for this I would modify the debloat script, correct? look at the nfq_codel_ll definitions in the file. There is an SFQ model in there too that might be interesting to try. the big problem is that no matter how much we twiddle up at this level there is still far too much queuing in the driver itself to see much effect (unless you hold the qlen vars at the levels they are at now) Ideally all the fq and aqm stuff happens *just before* an aggregate gets created. >> >> The larger quantum will also hurt, too.... right answer has always been = per station queues. > > Which I will happily test once they are implemented :) been 3 years since we started discussing it and looking for funding. > >> >> >> 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... > >> >> >> 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 c= orrelate with ethernet... > >> >> >> . Interestingly the classification really works in giving different band= width for the different classes. (And in rrul_noclassification, where the s= till classified UDP probes make it through the EF flow gets shorter latenci= es=85). >> >> having 4 full queues and a txop each is far worse than 1 queue with bett= er aggregation, IMHO. > > So, the one queue would need to shave off all TOS (excuse my occa= sional 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) kee= p 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 ge= t a better tx-ops sheduler? > >> >> >> Note that measuring through cerowrt to a wired host (with too rest= rictive firewall settings) get: >> >> >> You are seeing the upload ramp up along tcp's lines and the download ram= p down as it gets progressively more starved. > > The sum seems constant, so yes. > > >> >> >> with the MacBooks uplink still dominant (actually continually getting mo= re bandwidth=85). >> >> Well, you only have X bandwidth, in the air, total. A better way of sayi= ng 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? > >> >> Since I my only wireless connected machines are macs and nobody else com= plained about this issue I assume it is an osx issue >> >> 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, th= at's the part that matters. > > Oh, sure, and my quick and dirty real world test (bidirectional d= ata transfer initiated from the macbook turned out quite useable and balanc= ed). 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 etherne= t and I will be fine :) ) > > >> >> it IS possible to get the best of both worlds, but that's going to take = some driver rework. >> >> >> >> For comparison an RRUL test from the wired linux host to cerowrt, where = things look much better... >> >> >> >>> 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 l= aptop (I think it's still running 10.7) >> >> Yeah, good question whether this is the same in all macosx version= s? (Sonner or later I will switch to 10.9 and repeat the measurements=85) T= he 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 fr= om the wired machine at the same time, nicely splits the bandwidth evenly b= etween up and download, so this might be netsurf related... >> >> >> 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 > > > >> >>> >>> >>>>> Also, my understanding was that with rts/cts, the router was in contr= ol >>>>> of >>>>> that aspect of things? >>>> >>>> That is what I thought AS well, but it is not what I See with osx = 10.8. >>>> >>> >>> 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. >> >> I think we agree that the AP should show more self-confidence and = reject such requests more firmly :) >> >> >>> >>> It should be clear in a monitor-mode tcpdump (or a statistical summary = of packets). >> >> I am not really equipped to do this, with just one wireless notebo= ok at my disposal :) >> >> best >> Sebastian >> >> >> Now that you have your laptops running this stuff (AWESOME thank you!) >> >> If I can encourage you all to go outside, to like your nearest cybercafe= , or conference center, and run your rrul tests there... >> >> ... you'll find out just how bad the rest of the world is... (and get so= me good data). >> >> I routinely see 4-6 seconds of latency, and a bare megabit or two of act= ual bandwidth. The ONLY place Iv'e ever had decent wifi performance in a bu= sy area has been at ietf conferences.... >> >> >>> >>> --Aaron >> >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> >> >> -- >> Dave T=E4ht >> >> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscri= be.html > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html