[Cake] More on 'target' corner cases - rate/target/interval confusion?
Dave Taht
dave.taht at gmail.com
Tue Nov 3 07:31:25 EST 2015
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äht
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
<kevin at darbyshire-bryant.me.uk> 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 = 64;
> u64 rate_ns = 0;
> u8 rate_shft = 0;
> codel_time_t byte_target_ns;
> u32 byte_target = mtu + (mtu >> 1);
>
> if (rate) {
> rate_shft = 32;
> rate_ns = ((u64) NSEC_PER_SEC) << rate_shft;
> do_div(rate_ns, max(MIN_RATE, rate));
> while (!!(rate_ns >> 32)) {
> rate_ns >>= 1;
> rate_shft--;
> }
> } /* else unlimited, ie. zero delay */
>
> b->tin_rate_bps = rate;
> b->tin_rate_ns = rate_ns;
> b->tin_rate_shft = rate_shft;
>
> byte_target_ns = (byte_target * rate_ns) >> rate_shft;
>
>
> Later on we see:
>
>
> b->cparams.target = max(byte_target_ns, ns_target);
> b->cparams.interval = max(rtt_est_ns +
> b->cparams.target - ns_target,
> b->cparams.target * 8);
> b->cparams.threshold = (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 at computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc replace dev eth0 root cake bandwidth 1Mbit ; sudo tc-adv -s qdisc
> qdisc cake 8005: dev eth0 root refcnt 6 bandwidth 1Mbit diffserv4 flows rtt 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/16ths
> cake_set_rate(&q->tins[2], rate - (rate >> 2), mtu,
> US2TIME(q->target), US2TIME(q->interval)); //3/4 rate
> cake_set_rate(&q->tins[3], rate >> 2, mtu,
> US2TIME(q->target), US2TIME(q->interval)); //1/4 rate
>
> 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
More information about the Cake
mailing list