From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 7933821F676 for ; Sun, 1 Nov 2015 12:58:09 -0800 (PST) Received: by qkbr67 with SMTP id r67so4458015qkb.2 for ; Sun, 01 Nov 2015 12:58:07 -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=q5w/MgUUPtuEzwhPLnroOOMJdmE12eDeFX2fhLfGia0=; b=yxtZJWqmSoTEa9KGIggL8pEyNhrgIELOr6yfigeKVf2bda9Ons7eGTKXdGwtIDkz2d w7vqVJG/hw3abjj9PcvFhFmkSgEk5MbwkMoFPmLr1HpZxnJ9lDrcHK0qX40RFJhDy0kx hwf+r9rZ5Ig/oHMnXm9jjmI0PSME3LsOJNNtFTCyPcCCegbh+pQS4N0nTh+yn6tAZYfw spIjgihXxpNY5PkUCB5Pm1ixqQe+XXaBNh+dQMvSlDR2ytoF7zl0g9+LHiM/rHeH/vf2 fkeWUAC94bK71nS2AgA2dLmCKIPuNBVY5Q8mm1Vihw+ZykRYYH3xvgm65m02BmUhS81E Io9Q== MIME-Version: 1.0 X-Received: by 10.55.21.65 with SMTP id f62mr25324079qkh.46.1446411487729; Sun, 01 Nov 2015 12:58:07 -0800 (PST) Received: by 10.140.85.39 with HTTP; Sun, 1 Nov 2015 12:58:07 -0800 (PST) In-Reply-To: References: Date: Sun, 1 Nov 2015 20:58:07 +0000 Message-ID: From: Alan Jenkins To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] cake target corner cases? 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, 01 Nov 2015 20:58:31 -0000 On 01/11/2015, Sebastian Moeller wrote: > Dear cake committee, > > I just played around with the most recent sch_cake and noticed: > > user@computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc del dev eth0 root > user@computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc replace dev eth0 root c= ake > bandwidth 1Mbit ; sudo tc-adv -s qdisc > qdisc cake 8005: dev eth0 root refcnt 6 bandwidth 1Mbit diffserv4 flows r= tt > 100.0ms raw > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > capacity estimate: 1Mbit > Tin 0 Tin 1 Tin 2 Tin 3 > thresh 1Mbit 937504bit 750Kbit 250Kbit > target 18.2ms 19.4ms 24.2ms 72.7ms > interval 145.3ms 155.0ms 193.8ms 581.4ms > Here target is always 12.5% of interval instead of the expected 6.25% > 1/16 =3D 0.0625 > 72.7/581.4 =3D 0.125042999656 > 24.2/193.8 =3D 0.124871001032 > 19.4/155.0 =3D 0.125161290323 > 18.2/145.3 =3D 0.125258086717 > But the bandwidth is really low, so pushing target closer to the bandwidt= h > conserving side of the codel rationale might be fine, Pretty sure it's a minimum derived from the MTU ((mtu=3D1.5kbyte) * 8 bits/byte) / 1000 Mbit/s =3D 0.012s except I don't know where the .5 comes from, that's incredibly suspicious to have a round 1/8th :). The point is that if buffering falls below the MTU, the connection will be completely clobbered. In a way it's nice cake reports this in the target. Otherwise cake would claim the target is 5ms, but measurements would show the effective target is more than twice as high. > since latency is bad > to begin with and bandwidth also pretty scarce. But it might be interesti= ng > to do a few more measurements at low bandwidths to confirm that the 12.5%= of > interval logic holds water; one could also argue that people with such li= nks > (a lot of DSL lines have even less upload, so this certainly is not extre= me) > might think that any added ms of delay matters (more than bandwidth); > currently we leave the user no remedy... > > > This looks okay, except Tin3 has target at 7.3/101.0 =3D 0.0722772277228 = 7% of > interval. Looks like the same thing. > Both observations might actually be on purpose, but if so we should docum= ent > that behavior as expected, for example in the man page=E2=80=A6 > > Best Regards > Sebastian I'm afraid I can't help mention my old niggle :). _If_ you mention this alongside instructions for RRUL, I think you'd also want to explain^W mention the measurement increase for diffserv4 v.s. besteffort. I think the ICMP ping measurement increases by another 10ms on my connection (11500k down / 850k up, so an mtu is ~15ms). I concluded it was inherent in prioritization. Now I guess it's equal to the sum of target * bandwidth_fraction for each class "above" icmp ping (and could be tested). I have graphs from sqm with and without classification. I did test cake once and I think it's the same (otherwise would be a bug). https://dl.dropboxusercontent.com/u/49925445/bufferbloat.net/220-cdf-531414= .sqm_simplest_11500_850_atm40_udppingfix.svg https://dl.dropboxusercontent.com/u/49925445/bufferbloat.net/221-cdf-360505= .sqm_simple_11500_850_atm40_udppingfix.svg Warm regards Alan