On 05/25/2012 01:19 PM, Vasanthakumar Thiagarajan wrote:
> There is frequent downlink throughput drop to 0 when operating
> at the signal level between -42dBm to -53dBm. This has been root
> caused to the delay in releasing pending a-mpdu subframes in
> reorder buffer. Right now the timeout value is 400ms, there
> is also a race condition where timeout handler can be delayed
> to run at an extra timeout interval. This patch reduces the
> timout interval to reasonable 100ms and makes sure releasing
> pending frames are not skipped in the timeout handler by removing
> the flag (rxtid->progress) which can delay the timeout logic.
>
> Reported-by: Yu Yanzhi <yanzhiy@xxxxxxxxxxxxxxxx>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@xxxxxxxxxxxxxxxx>
[..]
> + for (idx = 0 ; idx < rxtid->hold_q_sz; idx++) {
> + spin_lock_bh(&rxtid->lock);
> + if (rxtid->hold_q[idx].skb) {
> + /*
> + * There is a frame in the queue and no
> + * timer so start a timer to ensure that
> + * the frame doesn't remain stuck
> + * forever.
> + */
> + agg_conn->timer_scheduled = true;
> + mod_timer(&agg_conn->timer,
> + (jiffies + HZ * (AGGR_RX_TIMEOUT) / 1000));
> + rxtid->timer_mon = true;
> spin_unlock_bh(&rxtid->lock);
> + break;
> }
> + spin_unlock_bh(&rxtid->lock);
> + }
Same question about the loop here as well.
Kalle
--
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
