From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 5754821F220 for ; Mon, 25 May 2015 12:46:49 -0700 (PDT) Received: by oiww2 with SMTP id w2so63358412oiw.0 for ; Mon, 25 May 2015 12:46:29 -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=mI6wSXBJOpRvhytkYwwcYHFoUHjBbDTjgIabm8wTx2k=; b=n8FD8cF52/OCybST+CykIPP0nxY/bZJje63BMHvp3mkB4c4R3Wr3PlkqKtacODNUe+ +rv9ExvLGpe5X2RdHxd5HihkJaVdjF7GTsLJqY91xRelsfWDSCQUyOLHG2huuZJAecNO wVYY42EYjxwBJOBhKpWAGXoJEAw5K16zzclRF8uwIuEEciaoLLMJWZ009ykfxFeAOhsr p0h+6fiuZ3unk5JJV+K8oJF9ELw+QBthppxh1RFG8/3UnakXJ9sh8jYNcCjV9f6pqbId ORs8WcZA6SmAgbHdYIchEs27CgFvS05tuCFlUtBrFx9gsZThgiYpcDT82LTxuSDYuG0t OxDA== MIME-Version: 1.0 X-Received: by 10.60.178.33 with SMTP id cv1mr17120841oec.11.1432583189422; Mon, 25 May 2015 12:46:29 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Mon, 25 May 2015 12:46:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 May 2015 12:46:29 -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: Mon, 25 May 2015 19:47:29 -0000 On Sun, May 24, 2015 at 9:47 PM, Jonathan Morton wr= ote: > >> On 24 May, 2015, at 08:14, Dave Taht wrote: >> >> at 100Mbit we had 5 megabytes of max queuing. I don't think this was >> jonathon's intent, as the default if no rate was specified was 1Mbyte. >> >> =E2=80=A6 On the other hand codel does not >> react fast enough to major bursts without engaging the out of >> bufferspace cake_drop which is pretty darn cpu intensive. > > The 1-megabyte default is not intended to reflect the highest possible li= nk rate. Frankly, if you=E2=80=99re triggering cake_drop() without involvi= ng truly unresponsive flows, then the buffer limit is too small - you need = to give Codel the time it needs to come up to speed. I definitely should m= ake cake_drop() more efficient, but that=E2=80=99s not the problem here. At this point I think that codel is too un-responsive to deal with tons of flows in slow start, even if fq'd. Pie does better. So I disagree. I think dropping at a sane, and pretty small buffer limit, is in-line with the theory and assumptions everyone has made about the right sizes for buffering (which is usually in the range of 50-100 packets at most speeds!) and what I just did is a win over excessive buffering - and a HUGE win on devices with many interfaces and memory limitations. 300+k of buffering is quite a lot at these speeds - the algorithm(s) settle down at about 90k at 100mbit, which leaves plenty of room for finer levels of control and an outside limit that is relatively sane. Fq_codel (with offloads at the 1000 packet default) could hit 64Megabytes and even without offloads would 1.5mbytes. A codel-ish algorithm that reacted faster on overload overall would be nice, and being number of flow sensitive in cake seems like a partial way to get there, and I have a few other ideas under test. > I consider it *far* less important to control the short-term length of in= dividual queues, compared to the latency observed by competing latency-sens= itive traffic. I share the opinion that fq is more important than aqm. AND: both are neede= d. However there are many other objectives that need to be met also - keeping the pipe filled and utilization high for starters. The ideal buffer length is 1 packet, all the time, no idle periods. trying to smooth out bursts. being resistant to attacks. etc. THIS STUFF IS HARD! we need better tools to look at it. In particular, examples of typical workloads would be saner than engineering to the dslreports or flent tests. > > And I also think that ECN and packet-drops are too crude a tool to contro= l queue length to the extent you want. Hence ELR - but that=E2=80=99s stil= l in the future. (How much funding do you think we can get for that?) At the moment, I am merely hoping that demand for those doing the work increases enough so that those potential funders (as opposed to buyers) that need it most are willing to sink an investment into those doing the work - and are satisified merely by having the ideas and code in deployable form earlier. Most of what I have fought personally is that with "employment" corps expect to also own the ideas, and here there is no such possibility. I have chosen to live in a yurt until the "problem" is solved enough to move into hardware... With open source methods, if corps stay maneuverable enough (as for example free.fr, openwrt derivatives, and google fiber are), they can capitalize on new inventions faster - but "owning the ideas" always seems to end up being a higher priority in many mindsets. There aren't enough minds on the planet, working together, to solve these problems working alone. >> On the >> gripping hand there becomes no right outer limit for a wildly variable >> 802.11ac wifi queue, with speeds from one to 1.5Gbit, but I sure would >> like a cake-mq that handled the existing queues right with less >> memory. > > Something that I haven=E2=80=99t had time to implement yet is a dual-mode= FQ, performing both flow isolation and host isolation. That seems like a = step towards what wifi needs, as well as more directly addressing the case = where swarms and sensitive traffic are running on different endpoints, with= out Diffserv assistance. Pretty sure that we need way more information down at the mac80211 layer. > However, the overall design I have in mind for a wifi-aware qdisc is a li= ttle bit inside-out compared to cake. Cake goes: > > shaper -> priority -> flows -> signalling -> queues > > =E2=80=A6or, with host isolation added: > > shaper -> priority -> hosts -> flows -> signalling -> queues > > What wifi needs is a bit different: > > (hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows -> signal= ling -> 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. You HAVE to accept some additional delays in queuing when you have lots of stations. some of what I was prototyping is applicable to that. I should start pushing branches for each idea, I guess. > Of course, since the priority layer is buried three+ layers deep, it=E2= =80=99s obviously not going to use hardware 802.11e support. I don't see a use for the QoS stuff as currently structured in cake. Too high up. > > - Jonathan Morton > --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67