> On 12 Apr, 2017, at 15:48, xnor <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
