Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #951 (new defect)

Opened 15 years ago

Last modified 10 years ago

cwmin for best effort traffic

Reported by: jingpu@rice.edu Assigned to:
Priority: minor Milestone:
Component: madwifi: driver Version: v0.9.2
Keywords: cwmin best effort madwifi Cc:
Patch is attached: 0 Pending:

Description

We recently bought and installed wireless cards CM9 that uses AR5213-ES chipset and MadWifi driver 0.9.2 on Linux kernel 2.6 . In our research project, we need to change cwmin for best effort traffic. We are supposed to simply run iwpriv ath0 cwmin 0 0 5 or iwpriv ath0 cwmin 0 1 5, depending on whether it's in ap mode or sta mode. It seems cwmin is locked for best effort traffic for unknown reason. I used "iwpriv ath0 cwmin 0 1 8 " and I found out cwmin didn't change at all. I could change this parameter for all other types of traffic, but not for best effort. I used the latest iwpriv version 28. I tried everything I can possibly think of but none worked. thanks in advance for your help, jingpu

Change History

10/12/06 06:41:16 changed by mrenzmann

  • priority changed from major to minor.
  • milestone deleted.

01/08/07 17:52:41 changed by idan@eircom.net

I seem to have this issue as well. Using DLink atheros cards (AR5212) and linux 2.6.8.1 kernel. Can set all queues when in STA mode, however cannot set best effort queue in AP mode (queue 0 0 / 0 1) for any of the parameters; cwmin, aifs and txoplimit (cwmax not tested). Ian

01/09/07 06:35:43 changed by mrenzmann

Please try if the issue persists in current trunk (r1886) and give a short feedback. Thanks.

01/09/07 13:10:02 changed by idan@eircom.net

Tried latest version (r1887) via svn and issue persists. Unable to set parameters for best effort queue when in AP mode using "iwpriv ath0 cwmin 0 0/1 cwmin_val" (and aifs,txoplimit). Setting "iwpriv ath0 abolt 0" changes the cwmin value from 3 to 4 for this queue, but does not resolve issue. Values are obtained by "iwpriv ath0 get_cwmin 0 0/1" (etc..). All other queues can be set and no issue when in STA mode. Ian

01/09/07 13:39:59 changed by mrenzmann

Thanks for the feedback.

01/15/07 15:28:34 changed by idan@eircom.net

I have run some experiments and from the throughputs and the delays it appears that the 802.11e parameters are not in fact being set, ie: it is not an issue with reporting the values for this queue. Also, forcing all the packets through one of the other unaffected queues seems to 'fix' this problem (force through queue 2) and allows the parameters to be set. Ian

03/12/07 18:03:13 changed by christhiggins17@msn.com

idan, or anybody,

If madwifi assumes all traffic is routed through hw queue 0, which it assumes is WME_AC_BK, how do you route traffic, or affix a program to a different hw queue. I understand that if I can set a different hw queue, such as hw queue 1 for WME_AC_BE, hw queue 2 for WME_AC_VI, or hw queue 3 for WME_AC_VO, I then can control 802.11e or QoS parameters (cwmin, cwmax, aifs, or txoplimit) for the station.

Thanks! -Chris

03/12/07 18:07:40 changed by christhiggins17@msn.com

I didn't mention; I'm using MadWifi with Fedora Redhad Linux on a few different machines (laptops and desktops), I'm also trying to run it using Debian Linux on two Soekris embedded computers, but no such luck yet. This is a wireless testbed for UCI, for testing 802.11e/QoS/VoIP parameters.

-Chris

03/19/07 10:06:11 changed by Abram

I'm having the same problem with SVN version 2199, today's version. I can't set the wme parameters of AC_BE in monitor mode. The only situation where I can alter them is in sta mode, and only if the station has associated with an access point.

Idan, how do you force all packets through one of the other unaffected queues?

03/19/07 10:08:54 changed by Abram

This ticket seems to address the same problem as Ticket #641

03/19/07 17:01:29 changed by Abram

I think I solved the problem for monitor mode:

In the file ieee80211_proto.c
In the function ieee80211_wme_updateparams_locked
In the check if the WME_AC_BE parameters should be restored after altering them:

if ((vap->iv_opmode == IEEE80211_M_HOSTAP &&
	     (wme->wme_flags & WME_F_AGGRMODE) != 0) ||
	    (vap->iv_opmode != IEEE80211_M_HOSTAP &&
	    (vap->iv_bss->ni_flags & IEEE80211_NODE_QOS) == 0) ||
	    (vap->iv_flags & IEEE80211_F_WME) == 0) {

By adding the line

if ((vap->iv_opmode == IEEE80211_M_HOSTAP &&
	     (wme->wme_flags & WME_F_AGGRMODE) != 0) ||
	    (vap->iv_opmode != IEEE80211_M_HOSTAP &&
	    (vap->iv_bss->ni_flags & IEEE80211_NODE_QOS) == 0 &&

            vap->iv_opmode != IEEE80211_M_MONITOR) ||

	    (vap->iv_flags & IEEE80211_F_WME) == 0) {

it becomes possible to also alter the WME_AC_BE parameters.

(follow-up: ↓ 13 ) 03/27/07 03:51:04 changed by Gautam D. Bhanage

Hi is a fix available for the other modes (except monitor) yet?

(in reply to: ↑ 12 ) 04/16/07 14:40:16 changed by idan@eircom.net

Nasty hack for forcing packets through one queue...

In ath/if_ath.c function ath_tx_start() after the case statement figuring out 'txq' add something like

txq = sc->sc_ac2q[WME_AC_VI];

(or WME_AC_VO etc...)

Ian