How to modify acktimeout, ctstimeout and TXOP limits in MadWifi driver?

What's txop?

I am not sure yet. I do know a bit about the registers which I think are used for ACK timeout and CTS timeout though. Let me explain.

I believe the ACK timeout are what the ar5k ended up calling "rate duration registers". These are specific per rate and for the rates that are capable of short preamble (802.11b rates 2Mbps, 5.5Mbps, and 11Mbps) there is another register you can use to set the 'rate duration' for short preamble. The HAL and our ath5k driver sets these registers upon reset. I do not believe this is necessary though -- these are static values and should just be set IMO if we change mode. Anyway, please have a look at ath5k in ath5k_hw_write_rate_duration() in hw.c for this.

The value used during rate duration will depend on what rate you are configuring the driver to TX ACKs at. By default (from Nick's tests) the defined 'control' rate for each rate is used. The control rate is listed per rate on the
AR5K_RATES_* macros in ath5k.h as the last element. For example:

        { 1, IEEE80211_RATE_OFDM, 54000, 12, 108, 4 } }         \

In here on rate 54Mbps, the control rate is the index 4, which is 24Mbps. I believe Atheros chose this by design based on IEEE-802.11 Ch 9.6 (after 802.11g changes). Now, note the control rates can be modified. So far it seem the only way to do this is by enabling some bits on the AR5K_STA_ID1 register. We currently do this on base.c by calling ath5k_hw_set_ack_bitrate_high(). We currently set up the ACK bit rate to the low rates as we are having problems with higher rates in ath5k (anything above 11M). This would sets ACK bit rates to 11b rates which is just 1Mbps and 2Mbps. It sees the AR5K_STA_ID1_ACKCTS_6MB sets the ACK rate to 6Mbps for higher rates than 11Mbps. All this needs more testing and verification.

At least within implementation on the 'rate duration' register so far the entire register may be used here and in that case a whole 32 bits are available. Not sure if that is a hard boundary here or if its actually less.

Then here's a curve ball. We also have a register AR5K_TIME_OUT, which is split into two to set an 'ACK timeout' and 'CTS timeout':

#define AR5K_TIME_OUT           0x8014                  /* Register Address */
#define AR5K_TIME_OUT_ACK       0x00001fff      /* ACK timeout mask */
#define AR5K_TIME_OUT_ACK_S     0
#define AR5K_TIME_OUT_CTS       0x1fff0000      /* CTS timeout mask */
#define AR5K_TIME_OUT_CTS_S     16

_S means shift.

We currently do not set these values other than what is set by default through the initvals per mode for each baseband MAC and per mode. For ar5211 we set this to:

        /*        a/XR        aTurbo      b           g(OFDM?)
gTurbo (N/A) */
        { AR5K_TIME_OUT,
                { 0x04000400, 0x08000800, 0x20003000, 0x04000400,

0x04000400 } },

For ar5212 we set this to:

        /*        a/XR        aTurbo      b           g (DYN)     gTurbo */
        { AR5K_TIME_OUT,
                { 0x03e803e8, 0x06e006e0, 0x04200420, 0x08400840,

0x06e006e0 } },

The value set seems to have to match the PLL clock. You do this by using ath5k_hw_htoclock() and to read from it ath5k_hw_clocktoh().

Using this for 802.11g this seems to be set to 0x840 = 2112 (base 10).

2112 / 40 = 52.8

So perhaps this is an upper limit on the ACK timeout. If so what does this do and what is the difference in behavior between reaching a timeout with this value than with the specific value in the rate duration? I am not sure yet. I think one of them must trigger a retransmit. We do at least match what the HAL current does except remember we are currently setting the ACK bit rates to lower bit rates.

These registers are sharply split. ACK and CTS can only use a 0x1fff mask of the 32 bits, which is 13 bits. For each value it leaves us with with the 3 Most Significant BIts as either unused or for some purpose we are not yet sure how to use.

Hope this helps. Also if you end up testing and getting more information please do let us know.

Luis

Hello Luis,

I'm sorry but I can understand you very well. Some questions:

Is the txoplimit. Is possible to change this parameter in Wmm mode with= =20
driver madwifi. but the maximum value of this is 8160 us. You have been talking about registers, but I don't understand about thi= s=20
question very well. The general idea is: acktimeout registers are=20 limiting the acktimeout value. aren't it?. The limitation then is in th= e=20
SW and not in the HW.

Other question is the next. is 52.8 in milisecons?. How you can obtain=20 this value?.
I have tested that for AR5212 you have the next limitations for acktime= out:

802.11ag: 370
802.11b: 740 (just 370 x 2)

Thanks for all.

bo */

).

--=20
Sandra Salmer=C3=B3n Ntutumu <[email protected]>
Tlf. Analog: +34 91 488 8703 / M=C3=B3vil: + 34 653 574 298 Tlf. IP desde FWD: 656212. Ext: 10 / Tel. IP desde EHAS: 010010 =46undaci=C3=B3n EHAS: Enlace Hispanoamericano de Salud - www.ehas.org Telemedicina rural para zonas aisladas de pa=C3=ADses en desarrollo

-
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html