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 9E00921F53C for ; Wed, 25 Nov 2015 10:23:33 -0800 (PST) Received: by obbnk6 with SMTP id nk6so45148200obb.2 for ; Wed, 25 Nov 2015 10:23:32 -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=olnPAuccB2awMpqEYOO4Vip2d/C87n1HqFo5xGRZSf0=; b=xbBRgKl7P5XZh5MWJt7x+rDpi4HY8/SIkcgSvTYiK28/OpykE5tUZwc0lsGOyUnJlF ShJb0wNgFe9b14u1+qA10W1W6eG/1TPmFe+HYnT1JUN+zjoz1XZ+/tSZpMbrz1Y1ee2i pr79aHzDx3K9meQnLQBMQEp1DWY0B7PDX7zQNgoBkqI7jhEFDoVx7l9mHHz2JsQraqt6 wH1LpJj39ulAiC7q2vRh7QCgvIcD+YPW8cm1TF5IEFxFooHc155oYxY1XrOfGi0QF4PQ Y2nzTmvGM8nzUvPagJwdZxRTBvoPKDTdEq3eGZzqMXHT3FXst7nhWiK0C9RuRQBMkU3N Ib8A== MIME-Version: 1.0 X-Received: by 10.182.230.163 with SMTP id sz3mr5783504obc.26.1448475812349; Wed, 25 Nov 2015 10:23:32 -0800 (PST) Received: by 10.202.50.130 with HTTP; Wed, 25 Nov 2015 10:23:32 -0800 (PST) In-Reply-To: <62B84B79-3092-480A-90D0-ED79955917D8@gmx.de> References: <62B84B79-3092-480A-90D0-ED79955917D8@gmx.de> Date: Wed, 25 Nov 2015 19:23:32 +0100 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] basic cake 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: Wed, 25 Nov 2015 18:23:55 -0000 I am under the impression that the best case RTT that can be obtained from dsl to the next hop gateway is in the 9ms range (no interleaving) or about 18ms (with interleaving) - no matter the packet size. It would be good to know what a basic ping does on a real dsl line, as that uses nearly the smallest possible packet size. Using a ping with a larger packet size, to compare. In setting up a proper emulation the rtt should be in there, in addition to the other calculations. What sort of dsl lines are out there? (does anyone still have 384k? 1mbit? on the uplink?) Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Wed, Nov 25, 2015 at 6:45 PM, Sebastian Moeller wrote: > Hi Dave, > > On Nov 25, 2015, at 18:30 , Dave Taht wrote: > >> On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller wro= te: >>> Hi Dave, >>> >>> On Nov 25, 2015, at 17:02 , Dave Taht wrote: >>> >>>> Last night I went about removing nearly every unproven "feature" that >>>> has been added to cake since july, in part to establish a baseline for >>>> a performance comparison directly against sqm-scripts with >>>> htb+fq_codel, on low end hardware, and in part, to be able to test >>>> each newer feature >>>> more fully on the testbed. >>> >>> Oh, shiny, want have ;) So the plan is to assess the performance= cost of each of the individual features to allow a better rationale to jus= tify keeping or rejecting specific ones? Sounds like a excellent idea. >> >> pithy note here: >> >> https://github.com/dtaht/bcake/commit/4b9e6035bfa0160fa3fdaddcf1722c1cf9= 24afa9 > > Oh, I am all for a) testing things properly before setting defaul= ts, b) actually expose toggles for important parameters (toggles that bette= r be followed, if I request "target 1 ms=E2=80=9D I am fine with cake whini= ng/complaining in the log, I am not fine with cake just (silently) doing wh= at it thinks best; but we have been there before and I failed to convince e= nough people on that approach, so that boat has sailed and now instead of o= ne cake with one toggle we have 2 cakes without toggles ;) (note I do like = the implement and test one change at a time approach,)) > >> >>> >>>> >>>> The very long list of commits is here, complete with pithy comments, >>>> in the separate repo. >>>> >>>> https://github.com/dtaht/bcake/commits/master >>>> >>>> I would like it if someone using a low end home router could benchmark >>>> this version of cake >>>> against the mainline version. >>> >>> Hrmmm, for that I would need to build my own firmwares, let=E2= =80=99s see whether I am up for that=E2=80=A6 oh, will newcake still accept= all of tc-adv=E2=80=99s command line arguments (and simply ignore them?) >> >> I am keeping the api for now. > > Great that will make comparative testing easier... > >> >> I note that first up is cake besteffort flowblind 384k and cake >> besteffort flowblind 1mbit, with 5ms target. > > My hypothesis is that cake will stay longer in the drop state tha= n required, effectively sacrificing more bandwidth (per flow) than necessar= y to reach the sojourn target. Cake=E2=80=99s approach to dequeue nicely ti= me based should make sure packet sojourn time will actually be a good corre= late at what happens at the real bottle-neck. Now I am curious what the res= ults will be? So to risk a prediction, without the target adjustment or the= 1 packet is always allowed shortcut original codel took, cake will sacrifi= ce more bandwidth reducing effective throughput. I have no good idea for la= tency of un-related sparse flows, but would assume they will suffer a bit a= s well (entering drop state immediately?). Anyway looking forward to the re= sults. > >> >> While we have established that "bad things happen", I really don't >> know what they look like. We have a lot of tools >> for generating traffic, but no pictures of what actually happens. > > Yes, +1 for better/more visualizations. > >> >> But you might want to skip this round of testing before we establish >> this baseline and move on. > > Given the sorry state of my home network, I probably should wait = a bit ;). > > Best Regards > Sebastian > >> >>> >>>> >>>> My plan, such as it is, is to keep simplifying, and testing. I still >>>> don't get the new hashing >>>> API.... >>>> >>>> This reduction effort was fruitful in that I found yet another way to >>>> reuse "now"=E2=80=A6 >>> >>> As long as there are few enough cycles between the uses that sou= nds wonderful, otherwise now degrades to once ;) >>> >>>> fixed one bug, maybe spotted another... >>>> >>>> Toke has been busy with flent, which has gained a really abusive 1000 >>>> tcp flows test, >>> >>> bidirectional by any chance? Sort of the full internet simulator= for home-routers? >>> >>> >>> Best Regards >>> Sebastian >>> >>>> and >>>> the ability to parse qdisc statistics, so long as you tell flent where >>>> to get them from: >>>> >>>> >>>> --test-parameter qdisc_stats_hosts=3Dlocalhost\ >>>> --test-parameter qdisc_stats_interfaces=3D$IFACE\ >>>> >>>> http://snapon.cs.kau.se/~d/newcake/t >>>> >>>> >>>> -- >>>> Dave T=C3=A4ht >>>> Let's go make home routers and wifi faster! With better software! >>>> https://www.gofundme.com/savewifi >>>> _______________________________________________ >>>> Cake mailing list >>>> Cake@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/cake >>> >