Re: [Cake] More on 'target' corner cases - rate/target/interval confusion?

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 3837 bytes --]



On 16/11/15 12:41, Jonathan Morton wrote:
>> Video & Voice can gang together to claim 3/4 bandwidth
>> still leaving 1/4ish to be battled between bulk & best effort…
> That’s the intended behaviour of the current settings, since Voice borrows all the bandwidth it uses from Video’s allocation.
>
> With Video reduced to a ½ allocation, Video + Voice should also be limited to ½ in total if there is competing saturating traffic.  It’s possible that you haven’t altered the “bandwidth balance” DRR weights to match the new allocations, which might cause such an artefact.
In which case, and this comes as no surprise at all, I really, really,
really don't have a clue how this works :-)  I apologise, can you explain?

I've noticed a difference between how the drr weights are calculated
between precedence/diffserv8 and diffserv4:

diffserv8:  does 7/8ths rate for each tin, 3/2 priority and 7/8
bandwidth sharing.  Rate & bandwidth sharing decrease, priority increases.

diffserv4:  (and this is from 'master' - none of my fiddling :-)

       /* class characteristics */
        cake_set_rate(&q->tins[0], rate, mtu,
                      US2TIME(q->target), US2TIME(q->interval));
        cake_set_rate(&q->tins[1], rate - (rate >> 4), mtu,
                      US2TIME(q->target), US2TIME(q->interval));
        cake_set_rate(&q->tins[2], rate - (rate >> 2), mtu,
                      US2TIME(q->target), US2TIME(q->interval));
        cake_set_rate(&q->tins[3], rate >> 2, mtu,
                      US2TIME(q->target), US2TIME(q->interval));

        /* priority weights */
        q->tins[0].tin_quantum_prio = quantum >> 4;
        q->tins[1].tin_quantum_prio = quantum;
        q->tins[2].tin_quantum_prio = quantum << 2;
        q->tins[3].tin_quantum_prio = quantum << 4;

        /* bandwidth-sharing weights */
        q->tins[0].tin_quantum_band = (quantum >> 4);
        q->tins[1].tin_quantum_band = (quantum >> 3) + (quantum >> 4);
        q->tins[2].tin_quantum_band = (quantum >> 1);
        q->tins[3].tin_quantum_band = (quantum >> 2);

Rate decreases. Priority increases. bandwidth sharing increases until
voice where it decreases again.  Bandwidth sharing mostly goes the
opposite way round to precedence/diffserv8 - that suggests one of them
is wrong.


>
>>> The tin-specific tuning of target and interval was introduced when Cake had a separate hard shaper per tin.  It was the obvious design at the time. Now that Cake uses soft shaping between tins (allowing any tin to use the full link bandwidth if uncontended), it’s possible that choosing identical target and interval for all tins might suffice.  Alternatively, we might choose an even more conservative strategy.
>>>
>>> But which - and how do we decide?
>> I've no idea!  I tried the following experiment:  set ingress & egress
>> b/widths to 2mbit & 448kbit respectively (like my parents adsl...on a
>> good day)  Ran a 'rrul8_splittin' and noted ping box_plot for each tin -
>> EF was about 30ms higher (120ms) than CS3 (90ms)  Thinking I'd found a
>> smoking gun and that 120ms was quite close to the EF target of 140ms I
>> tweaked code to copy tin 0 target across all tins .....  it barely made any
>> difference at all!
> Since you’re using saturating traffic in all tins, Voice will be operating in “deprioritised” mode to penalise this abuse, so a higher latency is entirely expected.  If you delete the EF bulk flows but leave the latency measurements in place, you should see a big latency advantage.
>
> As I tried to explain before, the Codel settings affect latency and throughput *within* flows rather than *between* them.  Since you are presently measuring using a between-flows methodology, it’s not surprising that you saw no difference.
>
>  - Jonathan Morton
>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]