Re: [Cake] Choosing a tin to work on

[Jonathan Morton <chromatix99@gmail.com>]

> On 12 Apr, 2017, at 15:48, xnor <xnoreq@gmail.com> wrote:
> 
> Hey,
> 
>>>                s64 tdiff = b->tin_time_next_packet - now;
>>>                if(tdiff <= 0 || tdiff <= best_time) {
>>>                    best_time = tdiff;
>>>                    best_tin = tin;
>>>                }
>> 
>> 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.
> that makes no sense to me.
> 
> best_time is initialized to some high value (though why is it not 0x7FFF FFFF FFFF FFFFL, the highest possible positive s64?) such that no matter how far tdiff is in the future, best_time will always be set to the lower tdiff.
> (Just like you would initialize a variable keeping track of the max to the lowest possible value, you set a min variable to the highest possible value.)
> 
> But if you wanted best_time to end up as the lowest value, then you would have to only set it if tdiff < best_time (or <= if you actually want to prefer the last tin if they happen to have the same tdiff), and not also if tdiff <= 0.
> 
> For example, if tdiff values were 5000, -5000, 0 then best_time would be set to 0. The last value less than or equal to zero will always win as best_tin.
> If all tdiff values are positive then best_time will end up as the lowest value however.

For some reason I never seem to have got the initial question post.  The two of you are broadly right though.

The intention here is:

- Find the highest-priority tin with a packet already due;
- If none are due yet, find the one with a packet due soonest.

This should have the same type of “soft priority” behaviour as the previous WRR version, but I was hoping it could reduce the latency for processing sparse low-latency tins while under steady bulk load.

 - Jonathan Morton