Johannes,
In testing today, I discovered that p54usb and b43 never advance beyond 1 Mb/s
when using the pid algorithm. When I monitored rc_pid_events in
/sys/kernel/debug/.../, I discovered the rate-setting details as follows:
3547 4302748627 pf_sample 12800 -9216 -9216 0
IIRC from debugging b43legacy in the past, this indicates that the pid code is
never seeing any successful transmissions. I debugged the code in
rate_control_pid_tx_status() and found that p54usb is passing 1 in
status.rates[0].count, thus the following fragment is handling each frame as
though it had retries, even though there were none:
/* We count frames that totally failed to be transmitted as two bad
* frames, those that made it out but had some retries as one good and
* one bad frame. */
if (!(info->flags & IEEE80211_TX_STAT_ACK)) {
spinfo->tx_num_failed += 2;
spinfo->tx_num_xmit++;
} else if (info->status.rates[0].count) {
spinfo->tx_num_failed++;
spinfo->tx_num_xmit++;
}
This is a regression introduced in commit 9ea2c74 "mac80211/drivers: rewrite the
rate control API".
The following patch fixes the problem. Is it right?
Index: wireless-testing/net/mac80211/rc80211_pid_algo.c
===================================================================
--- wireless-testing.orig/net/mac80211/rc80211_pid_algo.c
+++ wireless-testing/net/mac80211/rc80211_pid_algo.c
@@ -256,7 +256,7 @@ static void rate_control_pid_tx_status(v
if (!(info->flags & IEEE80211_TX_STAT_ACK)) {
spinfo->tx_num_failed += 2;
spinfo->tx_num_xmit++;
- } else if (info->status.rates[0].count) {
+ } else if (info->status.rates[0].count > 1) {
spinfo->tx_num_failed++;
spinfo->tx_num_xmit++;
}
Larry
--
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
