--- Comment #15 from Adrian Chadd <> ---
The problem seems to be a lack of correct feedback to the AMRR rate control
code. It doesn't get informed of the correct number of transmissions, failures
and retries, leading to it believing the correct thing to do is continue
bumping up the rate.

If you enable IEEE80211_DEBUG in your kernel config, rebuild, then enable
debugging via 'wlandebug +rate', you'll likely see the MCS rate continue
climbing towards MCS7 or MCS15. This only works in a very clean environment -
definitely not with 2GHz.

If you compile with IWN_DEBUG, then sysctl dev.iwn.0.debug=0x1, you'll see
information about transmissions and transmit completions. You'll likely see the
TX PLCP climb to MCS rate 0xf (MCS15) - with the retry and duration counts will
be very high.

I'm not sure if there's a quick fix. I think I'm going to have to add some 11n
awareness to the ratectl API (ie, so we can tell it how many retries, how many
successes, how many failures, the transmit duration) and then ensure it really
is being called upon completion of each sent frame - aggregate or otherwise.

As for the driver - there seems to be multiple places where frame transmisson
completes and the rate control code gets called. I'll have to audit these to
ensure it's, well, "right".

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to