Luca Muscariello <[email protected]> writes: > I will check that later, still unsure. > > First guess: the quantum component should influence only how close to a > fluid bit-wise approximation you are. > So cake gets closer by automatic adjustment. > > The computation of the correction factor should be done by computing the > probability that a packet > of a sparse flow loses priority because of the quantum. Bad setting, higher > probability, ideal setting 0 probability. > > So your formula seems still wrong to me...
The formula expresses the conditions under which a flow is guaranteed to be treated as sparse by the scheduler, under some quite strong assumptions (most notably that the sparse flow is sending packets at a fixed rate). It's derived from the fact that when a packet from the sparse flow arrives, it (in the worst case) has to wait for the bulk flow packet that just started getting service (i.e., wait for L/R), after which the sparse flow itself will get service (in time L_s/R), then it will have to wait for its queue to pass through a whole round of scheduling (LN/R) before it can get service as a sparse flow again. Adding these together, the inter-arrival time between sparse flow packets has to be greater then (L(N+1)+L_s)/R, which when converted to a rate gives the formula I mentioned. You are right, of course, that in the general case it will be different; but I was talking about the specific case of the fixed-rate sparse flow here... :) -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
