Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: George Amanakis <g_amanakis@yahoo.com>
Cc: <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Choosing a tin to work on
Date: Wed, 12 Apr 2017 10:15:29 +0100	[thread overview]
Message-ID: <322beef3-fd84-144c-6718-795eff0e4435@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <1698783902.612018.1491919195146@mail.yahoo.com>



On 11/04/17 14:59, George Amanakis wrote:
> Hi Jonathan,
>
> I have some questions regarding the algorithm to choose a tin to dequeue
> from in sch_cake.c:
> -----------8<------------
>         int oi, best_tin=0;
>         s64 best_time = 0xFFFFFFFFFFFFUL;
>
>         for(oi=0; oi < q->tin_cnt; oi++) {
>             int tin = q->tin_order[oi];
>             b = q->tins + tin;
>             if((b->sparse_flow_count + b->bulk_flow_count) > 0) {
>                 s64 tdiff = b->tin_time_next_packet - now;
>                 if(tdiff <= 0 || tdiff <= best_time) {
>                     best_time = tdiff;
>                     best_tin = tin;
>                 }
>             }
>         }
> -----------8<------------
>
> 1) best_time is defined as a positive signed integer, this equals to 78
> hours if I did the calculations right. Why did you choose this? Did you
> mean to define it as "-1"?
> 2) If you meant to define it as "-1", the condition "tdiff <= best_time"
> would not matter. I can see no case where "tdiff > 0" and "tdiff <=
> best_time".
>
> Could you shed some light into this?
>
> Thank you,
> George


I'll try to answer this based on a vague bit of understanding...and then 
Jonathan can shoot me down as well :-)

So the 'best_time' is signed because we can have a packet in a tin that 
is not yet due to be sent (a positive result...ie. we have got here 
early) and/or we can have a tin that is due now/overdue (a zero/negative 
result, we've got here late)

The complication is that we can have multiple tins overdue, so we want 
the highest priority *and* least overdue (least late) tin - this is the 
reason for searching in tin_order[oi] and as a result tdiff can be <=0 
and bigger than best_time.

best_time is initialised to the 'most early' time possible.


Kevin  (awaits to be shot at :-) )



  parent reply	other threads:[~2017-04-12  9:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1698783902.612018.1491919195146.ref@mail.yahoo.com>
2017-04-11 13:59 ` George Amanakis
2017-04-11 14:11   ` [Cake] Fw: " George Amanakis
2017-04-12  9:15   ` Kevin Darbyshire-Bryant [this message]
2017-04-12 12:48     ` [Cake] " xnor
2017-04-12 13:44       ` Jonathan Morton
2017-04-12 14:02         ` George Amanakis
2017-04-12 13:45       ` George Amanakis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=322beef3-fd84-144c-6718-795eff0e4435@darbyshire-bryant.me.uk \
    --to=kevin@darbyshire-bryant.me.uk \
    --cc=cake@lists.bufferbloat.net \
    --cc=g_amanakis@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox