From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B660E21F6E4 for ; Sun, 6 Dec 2015 08:08:22 -0800 (PST) Received: from hms-beagle.home.lan ([87.164.160.171]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LeBPM-1abeLV3Itw-00psqV; Sun, 06 Dec 2015 17:08:17 +0100 Content-Type: multipart/mixed; boundary="Apple-Mail=_86C16707-D411-4CC2-8682-2DB7E90E589A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 6 Dec 2015 17:08:53 +0100 Message-Id: <6F86FBB0-AA69-44F3-82D0-31465906974D@gmx.de> References: To: =?iso-8859-1?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:7mNtwJM2HLKt248P4oVRDRRie/NkdCnJJNmZ7nbO+HyC/SL3PN1 HEgyCmi8w3pDEwhhHjODZos9vrWrXvsAYDr3Re/rj56MFqqkfShhiEaAmUdeqY86TjGLQkK l4XYMGLxl9KbDhdSKPqPiz91z8cZer/Dz6XesTEuK0+0ug3n/qHKy0qd4G4YaASHBpuSZqI lRzu9GdlMMLLRsJ1ntvTw== X-UI-Out-Filterresults: notjunk:1;V01:K0:3f44HkuKw8c=:OmTNaBDZYwOdccZvJZHq1S SQMOmepXgIg1b18KyDuU17JzaoeiqDMhQaVlqkhEjXjV+KP2xpkVTb4sOMShmFTpIvOCxZqzI 1QOtcUmZjXYCWpUMUeKxnoViYRSU4PC8+ci9bkArvGW6WeDzlI4lJC8dabRggdw8d1Uwv5RJL sL/tscJebJh3lnYHRjzvNCNCbTpeKco9D1u9Pps5K71fUt7v6/1ZKipGO12qMPJCOTF32EfTI YXMwNOxOTrJHVjJP0szXKLZBU3l2gMyiAbygE4lEcd15l0YjAhjb59hHtcKanYNbnGTwnFCs8 pPRg/xogOAGBDFAnqkUVOcMEmULV9NztWHNr2//J6iVtlD3cEfvDR+AYfBdtP51+m3EJHC4vD szrRuLTHjZRFsBU/S3DH3QdzkQCgHImWZQt+U0sHXj61ekTRlOo76h4TngRKVwfORN4RlBX8E b12QfOX5MejbpRK9Zlf9wAUKtQBhfpFSQLMskvN4b1QMpf6ScJysO1hgEfe7Hy3HqFEg20t2B wJvJW+otUUHSncsQ9QdbHer64RHJWgrD65kw9AYKt95rlita5/m65373wTN/207u1zkvChfU5 /JGGVA0+r5loqnNilgcqiPnCcUwPvTfVMA1VXuNkkpN6GzvvKfh/Im4iLb/1mpbA481pHbl0x c9u/wGvp30Jy0XFw3/I3YOklIHmB6wnAuL7OfheZEYZoETcioX2hzIL92zishZTQMKfoU+YEb xCs3AavJdM/i5zgTNRAz8Xwbr+uipS8JHsMe1RUrRqH+79RTLxfjjMrYnw0= Cc: cake@lists.bufferbloat.net Subject: Re: [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 16:08:45 -0000 --Apple-Mail=_86C16707-D411-4CC2-8682-2DB7E90E589A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dave, since I am not really involved in cake development make out of my = comments what you will=85 Even though I added comments below, IMHO, the way to proceed is discuss = the statistics to pass back to tc, and define a set we agree to stick to = (sat least as a base set, potentially copied from the best of fq_codel = and HTB) and then ask the kernel and iproute2 folks to merge what we = have. Changes that improve performance will most likely be possible in = the future even if upstreamed already=85=20 On Dec 6, 2015, at 15:53 , Dave Taht wrote: > I find myself torn by 3 things. >=20 > 1) The number of huge wins in fixing wifi far outweigh what we have > thus far achieved, or not achieved, in cake. As we say at home =93der Spatz in der Hand ist besser als die = Taube auf dem Dach=94; so given that cake is almost baked and wifi needs = a lot more than simple go-faster-stripes maybe finishing cake while = getting wifi improved is achievable? >=20 > 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! >=20 > 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. Two questions: 1) was it really faster for long enough tests (and has anybody = accidentally looked at cpu temperatures once cake starts throttling)? 2) Bugs in sqm? I thought that cake=92s reason d=92=EAtre was not to = improve sqm-scripts=92 performance, but to make it simple for my mom to = setup up a decent latency conserving internet access. So performance = gains are sugar on top, but lack there of is not necessarily a merge = stopper? >=20 > In wearing these 3 hats, I would >=20 > 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 = evaluated. > 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. But since codel/fq_cdel are hard to set up, especially in = combination with a shaper; rough performance parity with HTB+fq_codel = might be sufficient justification for a merge. >=20 > If you want to take apart this batch with "flent", looking for > enlightenment, also, please go ahead. >=20 > 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) >=20 > Next up, a series testing the fq portions... >=20 > If someone (else) would like to fork cake again and do the two things > above, I'd appreciate it. >=20 > 3C) Most of the new statistics are pretty useless IMHO. Interesting, > but in the end I mostly care about drops and marks only. I do care about packet size (and max packet size). The kernel=92s = complicated rules when and which overhead to add or not to add are so = under-documented that one needs a way to figure out what information = reaches the qdiscs/shapers otherwise meaningful per-paket-overhead = accounting is not going to work. Max_packet size I see as the only way = to check wether Meta-packets hit the qdiscs or not. Even if cake does = not peel or always peel this is informative in my opinion. >=20 > 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. >=20 > 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. Being able to set up a decent shaper/codel combination in one = line of tc is already a win (but I repeat myself) >=20 > 3F) At the moment I'm favoring peeling at the current quantum rather > than anything more elaborate. Why quantum, why not simply at MTU boundaries? I seem to recall = that aggregates already carry information how many MTU segments they = consist out of which could be re-used? >=20 > 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.... >=20 > 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) >=20 > (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! >=20 > I also like keeping all the core values 64 bits, from a science = perspective. >=20 > 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... >=20 > 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... >=20 > and then there's ecn... >=20 > 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 >=20 > 0) >=20 > So I guess it does come down to - what are the "musts" for cake before > it goes upstream? Get the feature set defined (potentially strip contentious = features for the time being and merge them piecewise into the kernel = proper) as well as a statistics set so the communication with tc is = future proof enough for the near future. Then try to get it merged... > 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? I was under the impression, that you and Toke are currently = measuring the performance costs of the additional features so decisions = which features to include could be made based on their cost? > (cleaning up the api in the process?) Is it still "cake" if we do > that? In the end we all know =93the cake is a lie=94 so ;) Best Regards Sebastian >=20 > Because, damn it, 2016 is going to be the year of WiFi. >=20 >=20 > Dave T=E4ht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi --Apple-Mail=_86C16707-D411-4CC2-8682-2DB7E90E589A Content-Disposition: attachment; filename=invsqrt.c Content-Type: text/x-csrc; name="invsqrt.c" Content-Transfer-Encoding: 7bit #include #include #include main() { double cur, inv,sum1,sum2; int i; inv = cur = sum1 = sum2 = 0.0; for (i=1;i<16;i++) { sum1 += inv = 1.0/sqrt(i); printf("i=%d inv=%f sum2=%f\n",i,inv,sum1); sum2 += cur = 2.0 * (1.0/sqrt(i))/3.0; printf("i=%d cur=%f sum2=%f\n",i,cur,sum2); } } --Apple-Mail=_86C16707-D411-4CC2-8682-2DB7E90E589A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --Apple-Mail=_86C16707-D411-4CC2-8682-2DB7E90E589A--