On Wed, Oct 22, 2008 at 12:00 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2008-10-20 at 23:33 +0530, Sujith wrote: > >> > Can you explain the way it currently works in ath9k? >> > >> >> Alright, it goes something like this: > > Thanks. > >> * 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. 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. > >> * Pause the TID, i.e, add further frames to the TID's queue. >> * If ADDBA exchange is successful, resume TID. >> * Form aggregates from the TID's buffer list, send them out. >> ( Take care to maintain minimum HW queue depth for aggregation ) > > "maintain minimum HW queue depth"? In what way? You mean put in enough > frames? > >> * If ADDBA exchange fails, flush TID. >> * Send TID's pending frames as normal frames (non-ampdu) > > 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. Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
