From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 3E424201240 for ; Fri, 29 May 2015 10:50:09 -0700 (PDT) Received: by obew15 with SMTP id w15so63309120obe.1 for ; Fri, 29 May 2015 10:49:55 -0700 (PDT) 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=9hSgZZ10ftFxV2bL5eX98wGRbNUqQpJq33qdfEQ3C68=; b=yeg8DlzgNpA3bYCJyqLU8h2XCVFwd60eXSJxjQvlgbdA1XBWvYdhqaBVtqrKcIebuY utxThehwuKiLox2AQi+MNoKVIy6MGiSgOQLH9RZ7CdrfOtzxRvErbz+59Oii06485rsN jVeu4zfWASWZeoCe4pSwfohOJA5oqXbLIwSdBe+tBO1VIT8xHUqeTbdpDe2x1ZPOXWjN YZn8y8jrz/5rs293fCxs+SJbpVOJeM1O4IzGqqA9MYZel5L4n5kG4zmdcOF0eVfN8wc7 qYEP2oeZg4iIdFaND1ERmbV0iHtZg+248x3MFGeKGKjHyPxIPB8tDl+JE8SuBNdJYTy+ 1GTg== MIME-Version: 1.0 X-Received: by 10.60.178.33 with SMTP id cv1mr7989198oec.11.1432921795298; Fri, 29 May 2015 10:49:55 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Fri, 29 May 2015 10:49:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 May 2015 10:49:55 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake byte limits too high by 10x X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:51:07 -0000 On Fri, May 29, 2015 at 6:02 AM, Jonathan Morton wr= ote: >> > What wifi needs is a bit different: >> > >> > (hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows -> >> > signalling -> queues > >> Yep. > >> I don't see a huge need for "shaping" on wifi. I do see a huge need - as= a >> starting point - an airtime fair per station queue that is aggregation >> aware, and slightly higher up, something that is aware of the overall >> workload on the AP. > > Which is basically what I'm thinking of. "Airtime fair" is also known as > "proportional fair". You need to know the data rate to each station for > that. > > But knowing the data rate via minstrel, and the average expected time > between transit opportunities to each station (which could probably be > calculated rather than measured), would allow inferring certain things th= at > I currently do using the shaper in cake, such as the appropriate size for > the aggregate, and the amount of bandwidth that we can allow priority in. > The only reason I can't reliably do that in cake with the shaper disabled= is > because I can't sense the hardware link rate, which is exactly what minst= rel > is in charge of. > > Incidentally, I suspect that aggregates of equal temporal length are > valuable for multi station MIMO. > > It's also pretty obvious that selective link layer acks need to be acted = on, > and aggregates reformed for each transmit opportunity, whether a retry or > not. I'm very disappointed to hear that those things often aren't already > done, but it's probably a consequence of leaving that functionality to th= e > hardware vendors so far. It's even possible that the current mess of bina= ry > blobs is a consequence of the weak support for aggregation in the kernel. Hardware retry was very commonly used with very little control. So far as I know the ath9k driver is now nearly pure software retry, with very few smarts about it, but the infrastructure is there. Reforming aggregates (and also giving up) is something that you have, like 10us (don't quote me, relevant spec not at hand) to do. Even in a double buffered scenario, older hardware would have trouble doing that much work in that much time - and of course, nobody "got" how important it was to do aggregates better in the multi-station environment until recently. some hardware offloads aggregation entirely (iwl). And I've been meaning to check into the mwl driver stack since that is a new chipset I don't grok yet... and there are a few other new candidates..... > Probably not so much raw code (which autocorrected to coffee TWICE) can b= e > reused from cake, not least due to simply operating at a different layer = of > the stack, but I think a lot of the conceptual advances can. while I would like cake to one day stablize, it seems to be a good vehicle to experiment in also, at least for a while. ;). It is (to me at least, at the moment) more important that the ideas get thrashed out - despite the pent up demand for a better shaper elsewhere. Still, when (if) more resources arrive for make-wifi-fast, it will make sense to produce a wifi "ap" std qdisc that interacts with whatever ends up in mac80211, properly to give the two tiers of per-station fairness and per flow "breakup" on a per station basis - (I lean not towards calling it fq, I tend to think of it as "better packing into an aggregate") - and freezing cake. There are other issues up and down the stack on all sides. > - Jonathan Morton --=20 Dave T=C3=A4ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast