summaryrefslogtreecommitdiff
path: root/net/rfkill
diff options
context:
space:
mode:
authorHelmut Schaa <helmut.schaa@googlemail.com>2010-10-02 11:34:56 +0200
committerJohn W. Linville <linville@tuxdriver.com>2010-10-05 13:35:29 -0400
commitb34793ee27aa547fc9b4213f89036c9a0ecaad5d (patch)
tree10e244f45980d48cba3e30928956086ebc2ebb2c /net/rfkill
parent01e946f22ae4bafe370d263f2ef499b8b232aec1 (diff)
rt2x00: Work around hw aggregation oddity in rt2800
If a frame is not meant to be sent as AMPDU or part of it the hw might still decide to aggregate this frame if a previous frame started an AMPDU. However, this will limit the usefulness of the reported tx rate since the reported rate will be the one specified in the TXWI of the first frame and thus it is not possible to reliably caculate the number of retrys by substracting the reported tx rate from the tx rate in the TXWI. To fix this issue, only report the successful rate for frames that were not meant to be aggregated but ended up in an aggregate. Example: Frame A (MCS7, AMPDU=1) B (MCS7, AMPDU=1) C (MCS12, AMDPU=0, PROBE_RATE) Although frame C shoudn't be aggregated the hw might sill put it into an AMPDU together with A and B. If the transmission succeeds the tx status will contain MCS7 for all three frames. In that case we should only report MCS7 as success rate and avoid reporting MCS12-MCS8 as failed tx attempts as this will affect the future rate control decisions. This oddity might strike us in other scenarious as well but the most common "wrong" report happened for frames used to probe a different tx rate. This improves the rate control decisions notable. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'net/rfkill')
0 files changed, 0 insertions, 0 deletions