On Mon, May 25, 2009 at 06:52:41PM -0700, Jeff Hansen wrote:
> Hello,
>
> I found that upgrading from compat-wireless-2009-04-28 to
> compat-wireless-2009-05-11 caused a huge degradation in performance in AP
> mode. Before (with 04-28), I was able to get ~25 Mbps TCP iperf speeds up
> and down (with a madwifi client), and after upgrading I still get ~30 Mbps
> UDP download, but only ~2Mbps UDP upload (and TCP speeds about the same -
> 2Mbps).
>
> After bisecting a bit, I found that the "mac80211: set default QoS values
> according to spec" caused the performance degradation, so I'm guessing
> that ath9k is not writing the correct values to the QoS timing registers
> when it gets the configuration from mac80211. For now, I'm just reverting
> this patch in my builds.
Hm, thanks for reporting this but did you try to configure changing the
defaults first? The changes johannes did ensures we follow the IEEE spec
for defaults. These can be tuned though, for example my hostapd.conf has:
wme_enabled=1
wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
Through the nl80211 driver this is set when you call NL80211_CMD_SET_WIPHY,
and pass NL80211_ATTR_WIPHY_TXQ_PARAMS, which I expect hostapd should be doing.
If you're using wirelesss-extensions driver for hostapd I believe you get
stuck with the defaults. Anyway in ath9k this is handled by ath9k_conf_tx()
and we do respect the passed up values.
Can you try with adding:
driver=nl80211
To your hostapd.conf and also tweek the queue parameters as you see fit?
Luis
Jouni,
I re-submitted all of my patches, including a patch that fixes this
problem. I also tried the settings below, and got comparable performance.
-Jeff
---------------------------------------------------
"If someone's gotta do it, it might as well be me."
[email protected]
On Tue, 26 May 2009, Jouni Malinen wrote:
> On Tue, 2009-05-26 at 11:11 -0700, Jouni Malinen wrote:
>> On Tue, 2009-05-26 at 10:46 -0700, Luis Rodriguez wrote:
>>> On Mon, May 25, 2009 at 06:52:41PM -0700, Jeff Hansen wrote:
>
>> That 25/30 Mbps to 2 Mbps is quite a huge difference and in order for
>> QoS parameters to cause something like this, they would need to be
>> seriously wrong..
>
> And well, it turns out that the values are indeed seriously wrong.. cw
> min and max values are swapped by
> b4af0b7ffa5f448bd12f81d2539ee2155919d493.
>
> Jeff: if you have a chance, you could try swapping the cw_max = aCWmin
> and cw_min = aCWmax value to actually set cw_max = aCWmax and cw_min =
> aCWmin.. In addition to this, I would actually recommend adding the
> explicit tx_queue_data* parameters into hostapd.conf even if you are not
> using WMM. This should work around the current bug and it will also set
> the parameters in a way which are more suitable for an AP (the defaults
> set in mac80211 are for station mode). In other words, add following
> into hostapd.conf:
>
> tx_queue_data3_aifs=7
> tx_queue_data3_cwmin=15
> tx_queue_data3_cwmax=1023
> tx_queue_data3_burst=0
>
> tx_queue_data2_aifs=3
> tx_queue_data2_cwmin=15
> tx_queue_data2_cwmax=63
> tx_queue_data2_burst=0
>
> tx_queue_data1_aifs=1
> tx_queue_data1_cwmin=7
> tx_queue_data1_cwmax=15
> tx_queue_data1_burst=3.0
>
> tx_queue_data0_aifs=1
> tx_queue_data0_cwmin=3
> tx_queue_data0_cwmax=7
> tx_queue_data0_burst=1.5
>
> - Jouni
>
>
>
On Tue, 2009-05-26 at 10:46 -0700, Luis Rodriguez wrote:
> On Mon, May 25, 2009 at 06:52:41PM -0700, Jeff Hansen wrote:
> > I found that upgrading from compat-wireless-2009-04-28 to
> > compat-wireless-2009-05-11 caused a huge degradation in performance in AP
> > mode. Before (with 04-28), I was able to get ~25 Mbps TCP iperf speeds up
> > and down (with a madwifi client), and after upgrading I still get ~30 Mbps
> > UDP download, but only ~2Mbps UDP upload (and TCP speeds about the same -
> > 2Mbps).
> >
> > After bisecting a bit, I found that the "mac80211: set default QoS values
> > according to spec" caused the performance degradation, so I'm guessing
> > that ath9k is not writing the correct values to the QoS timing registers
> > when it gets the configuration from mac80211. For now, I'm just reverting
> > this patch in my builds.
That 25/30 Mbps to 2 Mbps is quite a huge difference and in order for
QoS parameters to cause something like this, they would need to be
seriously wrong..
I'm assuming that by "upload" you are referring to the case where a
station is transmitting data to the AP. One thing to note about that one
is that the QoS parameter change in the AP (i.e., the mac80211 change
mentioned here; I'm assuming you did not modify the client used in the
test) should actually have only a minor effect in the STA->AP
transmission.. As such, it is kind of surprising that this change would
cause such a difference.
> Hm, thanks for reporting this but did you try to configure changing the
> defaults first? The changes johannes did ensures we follow the IEEE spec
> for defaults. These can be tuned though, for example my hostapd.conf has:
>
> wme_enabled=1
> wme_ac_bk_cwmin=4
..
> wme_ac_vo_acm=0
>
> Through the nl80211 driver this is set when you call NL80211_CMD_SET_WIPHY,
> and pass NL80211_ATTR_WIPHY_TXQ_PARAMS, which I expect hostapd should be doing.
There are actually two sets of WMM/TX queue parameters in AP: one that
the AP uses itself and one that the AP requests the associated stations
to use. The wme_ac_* parameters are for the stations, not for the AP.
NL80211_ATTR_WIPHY_TXQ_PARAMS is used with the TX parameters for the AP,
i.e., tx_queue_data* parameters in hostapd.conf. I would recommend
explicitly specifying both of these sets to make sure both the AP and
stations end up using the expected values. Any change in mac80211 should
not affect the values the AP requests the client to use (wme_ac_*) which
are advertised in the WMM IE.
> If you're using wirelesss-extensions driver for hostapd I believe you get
> stuck with the defaults. Anyway in ath9k this is handled by ath9k_conf_tx()
> and we do respect the passed up values.
There is no wireless-extensions driver for hostapd, i.e., driver=nl80211
is the only available option with ath9k.
- Jouni
On Tue, 2009-05-26 at 11:11 -0700, Jouni Malinen wrote:
> On Tue, 2009-05-26 at 10:46 -0700, Luis Rodriguez wrote:
> > On Mon, May 25, 2009 at 06:52:41PM -0700, Jeff Hansen wrote:
> That 25/30 Mbps to 2 Mbps is quite a huge difference and in order for
> QoS parameters to cause something like this, they would need to be
> seriously wrong..
And well, it turns out that the values are indeed seriously wrong.. cw
min and max values are swapped by
b4af0b7ffa5f448bd12f81d2539ee2155919d493.
Jeff: if you have a chance, you could try swapping the cw_max = aCWmin
and cw_min = aCWmax value to actually set cw_max = aCWmax and cw_min =
aCWmin.. In addition to this, I would actually recommend adding the
explicit tx_queue_data* parameters into hostapd.conf even if you are not
using WMM. This should work around the current bug and it will also set
the parameters in a way which are more suitable for an AP (the defaults
set in mac80211 are for station mode). In other words, add following
into hostapd.conf:
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5
- Jouni