[RFC] minstrel_ht: fill out more than 3 rates

[RFC] minstrel_ht: fill out more than 3 rates

[Christian Lamparter]

Hello Felix,

I've stumbled into this conundrum a while ago...
then as usual: forgot that it existed, until yesterday:

As you know minstrel (our non ht fallback) enables mrr-mode
only if the driver sets hw->max_rates to 4 or more. 
minstrel_ht - on the other hand - just prepares a set
of 3 rates, so at least one additional retry with
different tx-vectors remains unused...

How the last tries should be used is up for debate,
I've opted out for lowest possible MCS.
(although, some devices may also use a legacy
 rate for the final tries...)

And the reason why I think it's worth to do an additional
round: The reordering penalty for lost MPDUs on the receiver-
side can be as high as 100ms, which is quite expensive compared
to some extra airtime...
---
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index c5b4659..5f44c0b 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -584,7 +584,7 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
 	struct minstrel_ht_sta_priv *msp = priv_sta;
 	struct minstrel_ht_sta *mi = &msp->ht;
 	struct minstrel_priv *mp = priv;
-	int sample_idx;
+	int sample_idx, i = 0;
 
 	if (rate_control_send_low(sta, priv_sta, txrc))
 		return;
@@ -595,21 +595,29 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
 	info->flags |= mi->tx_flags;
 	sample_idx = minstrel_get_sample_rate(mp, mi);
 	if (sample_idx >= 0) {
-		minstrel_ht_set_rate(mp, mi, &ar[0], sample_idx,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], sample_idx,
 			txrc, true, false);
-		minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_tp_rate,
 			txrc, false, true);
 		info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
 	} else {
-		minstrel_ht_set_rate(mp, mi, &ar[0], mi->max_tp_rate,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_tp_rate,
 			txrc, false, false);
-		minstrel_ht_set_rate(mp, mi, &ar[1], mi->max_tp_rate2,
+		minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_tp_rate2,
 			txrc, false, true);
 	}
-	minstrel_ht_set_rate(mp, mi, &ar[2], mi->max_prob_rate, txrc, false, true);
+	minstrel_ht_set_rate(mp, mi, &ar[i++], mi->max_prob_rate,
+			     txrc, false, true);
 
-	ar[3].count = 0;
-	ar[3].idx = -1;
+	for (;i < mp->hw->max_rates; i++) {
+		minstrel_ht_set_rate(mp, mi, &ar[i++], 0,
+				     txrc, false, true);
+	}
+
+	for (; i < IEEE80211_TX_MAX_RATES; i++) {
+		ar[i].count = 0;
+		ar[i].idx = -1;
+	}
 
 	mi->total_packets++;
 

Re: [RFC] minstrel_ht: fill out more than 3 rates

[Felix Fietkau]

On 2010-08-07 12:07 AM, Christian Lamparter wrote:
> Hello Felix,
> 
> I've stumbled into this conundrum a while ago...
> then as usual: forgot that it existed, until yesterday:
> 
> As you know minstrel (our non ht fallback) enables mrr-mode
> only if the driver sets hw->max_rates to 4 or more. 
> minstrel_ht - on the other hand - just prepares a set
> of 3 rates, so at least one additional retry with
> different tx-vectors remains unused...
> 
> How the last tries should be used is up for debate,
> I've opted out for lowest possible MCS.
> (although, some devices may also use a legacy
>  rate for the final tries...)
> 
> And the reason why I think it's worth to do an additional
> round: The reordering penalty for lost MPDUs on the receiver-
> side can be as high as 100ms, which is quite expensive compared
> to some extra airtime...
The problem here is that we have very different forms of retransmission
that receive the same kind of tx rate information, even though they
should be treated in a different way.

With drivers like ath9k, we don't need many retransmission steps. The
hardware-level retransmission stops as soon as it receives a Block Ack,
even if that may only ACK one of many frames (or maybe even none at
all). Software retransmission is then used to ensure that we don't
usually see lost MPDUs (under sane conditions, software-level excessive
retries should be pretty rare).

With this form of aggregation, the processing of the MRR chain is always
restarted for the next transmission attempt.
Since the table is for hw-level retransmission only, we do need to
ensure that we don't put unnecessarily low rates into the MRR array, as
this will limit aggregation size based on the 4-ms limit.

When using hardware aggregation, the behaviour kind of depends on how
the hardware interprets the retransmission information and how many
times it retransmits failed subframes of an A-MPDU transmission that
received a Block Ack.

I think in the long run we need to split this up. In my software
aggregation rewrite, I plan to add rate control lookups per A-MPDU, so
that the rate control algorithm can make a decision based on the number
of failed subframes (or the delta between first frame seqno and last
frame seqno, to better utilize the block ack window). In this case, the
rate control can be (and should be) much more optimistic about rates,
whereas with hardware aggregation we should probably put more emphasis
on reliability to reduce the latency.

- Felix