On Wed, Nov 20, 2013 at 03:04:34PM +0100, Felix Fietkau wrote:
> On 2013-11-20 14:56, Karl Beldan wrote:
> > On Wed, Nov 20, 2013 at 08:32:32AM +0100, Felix Fietkau wrote:
> >> On 2013-11-20 01:51, Karl Beldan wrote:
> >> > From: Karl Beldan <karl.beldan@xxxxxxxxxxxxxxxx>
> >> >
> >> > Commit 3e8b1eb "mac80211/minstrel_ht: improve rate selection stability"
> >> > introduced a local capped prob in minstrel_ht_calc_tp but omitted to use
> >> > it to compute the rate throughput.
> >> >
> >> > Signed-off-by: Karl Beldan <karl.beldan@xxxxxxxxxxxxxxxx>
> >> > CC: Felix Fietkau <nbd@xxxxxxxxxxx>
> >> Nice catch!
> >> Acked-by: Felix Fietkau <nbd@xxxxxxxxxxx>
> >>
> > Interestingly enough, consecutive coding rates (5/6, 3/4, 2/3) max ratio
> > is 9/10, did you do it on purpose ? (e.g. (9/10) * (5/6) == 3/4,
> > (9/10) * (3/4) == 2/3 + 11/120).
> The change has nothing to do with coding rates, it's only about
> retransmissions caused by collisions under load.
>
I understand this, my point was that along with this comes the following:
let's say my SNR is just not so good to get 5/6 as good as 3/4, and e.g.
case1 htMCS7 has 91%
htMCS6 has 100% success
case2 htMCS7 has 80%
htMCS6 has 100% success
capping at 90% will prefer htMCS7 in case1 and htMCS6 in case2 both
achieving best real throughput.
capping at 80% will prefer htMCS7 in case1 _but_ htMCS7 in case2 the
latter being the worst real throughput(90% of 5/6 == 100% of 3/4 > 80%
of 5/6).
Karl
--
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
