From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 B8A0621F197 for ; Tue, 3 Nov 2015 04:31:26 -0800 (PST) Received: by obdgf3 with SMTP id gf3so10629612obd.3 for ; Tue, 03 Nov 2015 04:31:25 -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=6paBBazp3TkiHwukDZdMCSZ+sEei1r0Kji/eTn7nBk8=; b=ZgR0PA74YAW1FpNW5GKy455M0hK9FKMqpKTtfvUuZHtDWv0wyGwP8dU0U04p3xxB/t LThnNiUIbZK/WP5sZTfuMXlkz1z+kKejGlry5xHtMtI0T8oa08j7yfutbGFzp3jKaZy8 4AwMdCDHvLBMbFEnQDmasmN60jTEJcjhABd8hSu9ObLOAcw1VMMz4N7xtBfZK2v8M4Xl V3jy+ekSgaxlwIRjf3DJzpZCN4xdggsUFL2Depm3nKzsg4+HbSoDe37SkWEUBdm/JowJ RM/sohm5JLWZ8oACKU10B9/irPpLLzbYnZlFID4XCM3uBLHyIng8G9yhk+6KhAJclwds QPqg== MIME-Version: 1.0 X-Received: by 10.60.41.9 with SMTP id b9mr17856700oel.37.1446553885685; Tue, 03 Nov 2015 04:31:25 -0800 (PST) Received: by 10.202.61.133 with HTTP; Tue, 3 Nov 2015 04:31:25 -0800 (PST) In-Reply-To: <5638A4F4.2010701@darbyshire-bryant.me.uk> References: <5638A4F4.2010701@darbyshire-bryant.me.uk> Date: Tue, 3 Nov 2015 07:31:25 -0500 Message-ID: From: Dave Taht To: Kevin Darbyshire-Bryant Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] More on 'target' corner cases - rate/target/interval confusion? 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: Tue, 03 Nov 2015 12:31:48 -0000 as for the voice class, we always have the problem of mis-classification into that tin. Aside from that, I believe you are right, that target/interval should be tighter on that class in general. At least some versions of debloat.sh and the debloat lua script for wifi actually did that. Some versions also disabled ecn on the voice class also. There is certainly some thinking out there that argues in favor of dropping everything but the last few packets per flow in the voice class... rather than applying something as complex as fq_codel to it. I appreciate you taking the time for obsessive, deep thoughts like this. For the past 6 months I've had the workload of hercules, and the attention span of a hummingbird on crack. Nowadays, despite the conventional wisdom, I tend to favor the idea of allowing ecn, even on voice, now that we have other means of kicking in drops when ecn is present. Also, conventional thinking on voice is generally old style single rate GSM encoded packets, (something like 120 bytes/20ms). where the future I would like to live in is opus 48khz 6 way surround sound with 2.7 ms latency on the encoder, and I don't know how that should be treated as to queue depth and jitter, in a DRR (byte based) system, without testing. It would be great to upgrade to that sort of opus based flow when analyzing voice behavior under cake, perhaps driven by an asterisk or freeswitch or other musical over the internet application (LOLA anyone?) https://www.opus-codec.org/ Dave T=C3=A4ht I just invested five years of my life to making wifi better. And, now... the FCC wants to make my work, illegal for people to install. https://www.gofundme.com/savewifi On Tue, Nov 3, 2015 at 7:13 AM, Kevin Darbyshire-Bryant wrote: > Hi List, > > I'm still not supposed to be here (I'm working) and I'm full of a cold > still however the same/similar questions keep coming up and it prompts a > follow up 'base' question that I don't know the answer to. So the > background: Targets. > > In the absence of any other instruction and assuming either a) > sufficiently fast rate/unlimited, the first cake classification tin will > be set to 'interval/16', for 100mS this is 6.25mS. Where a rate *is* > specified then this calculation is performed (I can't get my cold addled > head round this at the moment, but suffice it's an integer division only > dodge and 'magics' up the time for a MTU * 1.5 packet to flow > (byte_target_ns) Wonderful, no problem here. > > cake_set_rate(.....) > > /* convert byte-rate into time-per-byte > * so it will always unwedge in reasonable time. > */ > static const u64 MIN_RATE =3D 64; > u64 rate_ns =3D 0; > u8 rate_shft =3D 0; > codel_time_t byte_target_ns; > u32 byte_target =3D mtu + (mtu >> 1); > > if (rate) { > rate_shft =3D 32; > rate_ns =3D ((u64) NSEC_PER_SEC) << rate_shft; > do_div(rate_ns, max(MIN_RATE, rate)); > while (!!(rate_ns >> 32)) { > rate_ns >>=3D 1; > rate_shft--; > } > } /* else unlimited, ie. zero delay */ > > b->tin_rate_bps =3D rate; > b->tin_rate_ns =3D rate_ns; > b->tin_rate_shft =3D rate_shft; > > byte_target_ns =3D (byte_target * rate_ns) >> rate_shft; > > > Later on we see: > > > b->cparams.target =3D max(byte_target_ns, ns_target); > b->cparams.interval =3D max(rtt_est_ns + > b->cparams.target - ns_target, > b->cparams.target * 8); > b->cparams.threshold =3D (b->cparams.target >> 15) * > (b->cparams.interval >> 15) * 2; > > > This tin's target is set to our calculated 'fat packet' transit time > *OR* our requested time, whichever is the larger. Similarly interval is > set to our requested target (yes I'm missing some stuff out!) or > target*8, again whichever is larger. I've no problem with any of this, > though it does silently override requested parameters. The > problem/question comes when combined with our diffserv/tin > classification, as ably demonstrated by this: > > 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 > > > Note that as rate decreases, target & interval increase as per the above > algorithm. We can see why: > > cake_config_diffserv4(struct Qdisc *sch) > /* class characteristics */ > cake_set_rate(&q->tins[0], rate, mtu, > US2TIME(q->target), US2TIME(q->interval)); //Base > rate > cake_set_rate(&q->tins[1], rate - (rate >> 4), mtu, > US2TIME(q->target), US2TIME(q->interval)); //15/16= ths > cake_set_rate(&q->tins[2], rate - (rate >> 2), mtu, > US2TIME(q->target), US2TIME(q->interval)); //3/4 r= ate > cake_set_rate(&q->tins[3], rate >> 2, mtu, > US2TIME(q->target), US2TIME(q->interval)); //1/4 r= ate > > http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical makes > reference to the bandwidth allocation but makes no reference to its > affect on targets/intervals for that tin. Can someone please explain if > the above is actually correct and why. i.e. I'm confused why voice > traffic has a target latency of 72mS over a measurement interval of 1/2 > second when I'd have thought keeping voice latency as low as possible > would be the ideal. I'm sure I'm being exceptionally stupid so I await > education please :-) > > Kevin > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake >