From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (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 32EF521F676 for ; Sun, 6 Dec 2015 06:53:32 -0800 (PST) Received: by ykdr82 with SMTP id r82so169917678ykd.3 for ; Sun, 06 Dec 2015 06:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hrGBUOk1DuUoCcKboD+Jwzhv8j74FLyM4eoDZxVsvIM=; b=aZSCaQyr7YQqYfrUmOMLamu5rNfYYJWsfiHHiD3Iw3fblahjY52Sp8tNHJpsGQJC+M JwYqtkWIT5WI2Klv1NenuCoMEH4SXfrj9Vxephb/GkXvLFwDATl1xiNvokUq+KDLb7ME 4XVGq+TKqOGnhKgpi35p14r/WPV+A+jMd158BjVTMq7qv4596rQSFtCK786tYyeC40NJ ZebVU5070sO6/hpblcwY5FGGY6hUuG4Di84AtzbkverQSZwIiRdiJLy7DZl2TtZfYEr6 3obzT6Yd6SDgA4JyU+1K0XHhg8dCYxmMkfVDylIAEFHP2dJUsZNAjkz0/35q1bIVtoGv /F8Q== MIME-Version: 1.0 X-Received: by 10.129.99.195 with SMTP id x186mr18374802ywb.345.1449413610823; Sun, 06 Dec 2015 06:53:30 -0800 (PST) Received: by 10.37.210.145 with HTTP; Sun, 6 Dec 2015 06:53:30 -0800 (PST) Date: Sun, 6 Dec 2015 15:53:30 +0100 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net Content-Type: multipart/mixed; boundary=001a114920f868e17805263be702 Subject: [Cake] second system syndrome 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: Sun, 06 Dec 2015 14:53:55 -0000 --001a114920f868e17805263be702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I find myself torn by 3 things. 1) The number of huge wins in fixing wifi far outweigh what we have thus far achieved, or not achieved, in cake. 2) Science - Cake is like wet paint! There knobs to fiddle, endless tests to run, new ideas to try... measurements to take! papers to write! 3) Engineering - I just want it to be *done*. It's been too long. It was demonstrably faster than htb + fq_codel on weak hardware last june, and handled GRO peeling, which were the two biggest "bugs" in sqm I viewed we had. In wearing these 3 hats, I would 3A) like to drop cake, personally, from something I needed to care about. 3B) But, can't, because the profusion of features need to be fully evaluate= d. In this test series: http://snapon.cs.kau.se/~d/bcake_tests/ neither cake or bcake were "better" than the existing codel in any measurable way, and in most cases, worse. bcake did mildly better at a short (10ms) RTT... which was interesting. If you want to take apart this batch with "flent", looking for enlightenment, also, please go ahead. Were I to short circuit the science here, I'd rip out the sqrt cache and fold back in mainline codel into cake. This would also have the added benefit of also moving us back to 32bitland for various values (tho "now" becomes a bit trickier) and hopefully improving cpu efficiency a bit further (but this has to get done carefully unless your head is good at 32 bit overflow math) Next up, a series testing the fq portions... If someone (else) would like to fork cake again and do the two things above, I'd appreciate it. 3C) Most of the new statistics are pretty useless IMHO. Interesting, but in the end I mostly care about drops and marks only. 3D) Don't have a use for the rate estimator either, and so far the dual queue idea has not materialized. I understand how it might be done now - using the 8 way set associative thing per DEST hash, but I don't really see the benefit of that vs just using a DEST hash in the first place. 3E) Want cake to run as fast as possible on cheap hardware and be a demonstrable win over htb + fq_codel - and upstream it and be done with it. 3F) At the moment I'm favoring peeling at the current quantum rather than anything more elaborate. 3G) really want the thing to work correctly down to 64k and up to at least a gbit. which needs testing... but probably after we pick a codel.... 2A) As a science vehicle, there are many other things we could be trying in cake, and I happen to like the idea of the (currently sort) cache in for example, trying a faster curve at startup - or, as in the ns2 code - a harder curve at say count + 128 or even earlier, as the speed up in drops gets pretty tiny even at count + 16. (see attached) (it doesn't make much sense to calculate the sqrt at run time - you can just calculate the constants elsewhere and plug them in, btw. attached is a teeny proggie that does that an also explores a harder initial curve (you'd jump count up to where it matched the curve when you reverted to the invsqrt calculation) - and no, I haven't tried plugging this in either... DANGER! Wet Paint! I also like keeping all the core values 64 bits, from a science perspective= . There are also things like reducing the number of flows, and exercising the 8 way associative cache more - to say 256, 128, or even 32? Or relative to the bandwidth... or target setting... and I do keep wishing we could at the very least resolve the target > mtu issue. std codel turns off with a single mtu outstanding. That arguably should have been all that was needed... and then there's ecn... 1A) Boy do we have major problems with wifi, and major gains to be had 1B) All the new platforms have bugs eveyerhwer, including in the ethernet drivers 0) So I guess it does come down to - what are the "musts" for cake before it goes upstream? How much more work is required, by everybody, on every topic, til that happens? Can we just fork off what is known to work reasonably well, and let the rest evolve separately in a cake2? (cleaning up the api in the process?) Is it still "cake" if we do that? Because, damn it, 2016 is going to be the year of WiFi. Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi --001a114920f868e17805263be702 Content-Type: text/x-csrc; charset=US-ASCII; name="invsqrt.c" Content-Disposition: attachment; filename="invsqrt.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ihun6vk40 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPG1hdGguaD4K Cm1haW4oKSB7CmRvdWJsZSBjdXIsIGludixzdW0xLHN1bTI7CmludCBpOwoJaW52ID0gY3VyID0g c3VtMSA9IHN1bTIgPSAwLjA7CmZvciAoaT0xO2k8MTY7aSsrKSB7CglzdW0xICs9IGludiA9IDEu MC9zcXJ0KGkpOwoJcHJpbnRmKCJpPSVkIGludj0lZiBzdW0yPSVmXG4iLGksaW52LHN1bTEpOwoJ c3VtMiArPSBjdXIgPSAyLjAgKiAoMS4wL3NxcnQoaSkpLzMuMDsKCXByaW50ZigiaT0lZCBjdXI9 JWYgc3VtMj0lZlxuIixpLGN1cixzdW0yKTsKCX0KfQoK --001a114920f868e17805263be702--