On Wed, 2008-10-22 at 13:41 +0200, Tomas Winkler wrote: > >> * mac80211 sends down a frame > >> * Initiate an aggregation session for the <RA,TID> if one isn't already in progress. > > > > It seems that should be a rate control decision? Possibly taking into > > account more than just always doing aggregation sessions. Then again, I > > suppose aggregation sessions are cheap. What about latency here? > > Aggregation has it's overhead, both computing resources and on the > air. Obvious that it has negative affect on latency so if the 'minimum > HW queue depth' is not satisfied the packets > are delayed till the queue is full enough. That would be "do I have enough frames to aggregate them"? > In iwl-agn-rs scale we keep track of current tpt to take decision > about starting aggregation. The throughput watch can be viewed as > different entity it was just convenient and conceptually fit to > incorporate into rate scale. Sure, that kinda makes sense. The RC algorithm is conceptually responsible for making sure things go as fast as possible :) > > Obviously. But why isn't this done in parallel? I mean, why not send out > > the frame and do addba and don't aggregate until addba was successful, > > that would mean no latency for those frames... addba could even time out > > which would add a lot of latency, no? > > The negotiation is done on starting sequence number. Ah, good point. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
