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@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