Re: [support] ath5k contention windows

Re: [support] ath5k contention windows

[Jonathan Guerin]

Hi all,

I have some behaviour I'm observing with some Atheros cards we use
that doesn't seem to match what the initvals of ath5k are set up to.
These are the cards I used:
http://www.mini-box.com/s.nl/it.A/id.387/.f

I have run a saturated iPerf flow on a conducted testbed with both
stations being inside RF-shielding boxes. They are set to 802.11a
mode, on channel 1. I then parse the trace, looking for ACK-DATA
pairs, and calculating the time difference between them. From this, I
remove the TX_TIME of the DATA frame, as well as a DIFS:

ACK_TIMESTAMP + DIFS + CONTENTION_TIME + DATA_TX_TIME = DATA_TIMESTAMP

which will leave me with the CONTENTION_TIME. Dividing this time by a
SLOT_TIME will give me the slot which was chosen by the hardware.


According to the driver, in ath5k.h:

#define AR5K_TUNE_CWMIN                15

CWMIN is initialised to 15.

The actual distribution of contention slots I'm observing resembles this:

Slot Number,Count
0,1315
1,1302
2,1249
3,1291
4,1347
5,1219
6,1249
7,0
8,0
9,0
<truncated>

as well as 1360 frames which came in with a negative CONTENTION_TIME.

Ignoring the fact that some frames are coming up with a negative
CONTENTION_TIME (which potentially points to another problem), what is
being observed here is that CW_MIN appears to start at 7, rather than
the 15 which it should be.

I'm just wondering if anyone would have any idea why this is occurring?

Thanks,

--
Jonathan Guerin

PS sorry for the double-post, the system complained as my message was
originally in HTML

Re: [ath5k-devel] [support] ath5k contention windows

[Bob Copeland]

On Tue, Sep 14, 2010 at 1:51 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
> as well as 1360 frames which came in with a negative CONTENTION_TIME.
>
> Ignoring the fact that some frames are coming up with a negative
> CONTENTION_TIME (which potentially points to another problem)

How negative are these?  Are you subtracting more for, say, txtime
than you should be?

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [support] ath5k contention windows

[Nick Kossifidis]

2010/9/14 Jonathan Guerin <jonathan@guerin.id.au>:
> Hi all,
>
> I have some behaviour I'm observing with some Atheros cards we use that
> doesn't seem to match what the initvals of ath5k are set up to. These are
> the cards I used:
> http://www.mini-box.com/s.nl/it.A/id.387/.f
>
> I have run a saturated iPerf flow on a conducted testbed with both stations
> being inside RF-shielding boxes. They are set to 802.11a mode, on channel 1.
> I then parse the trace, looking for ACK-DATA pairs, and calculating the time
> difference between them. From this, I remove the TX_TIME of the DATA frame,
> as well as a DIFS:
>
> ACK_TIMESTAMP + DIFS + CONTENTION_TIME + DATA_TX_TIME = DATA_TIMESTAMP
>
> which will leave me with the CONTENTION_TIME. Dividing this time by a
> SLOT_TIME will give me the slot which was chosen by the hardware.
>
>
> According to the driver, in ath5k.h:
>
> #define AR5K_TUNE_CWMIN                15
>
> CWMIN is initialised to 15.
>
> The actual distribution of contention slots I'm observing resembles this:
>
> Slot Number,Count
> 0,1315
> 1,1302
> 2,1249
> 3,1291
> 4,1347
> 5,1219
> 6,1249
> 7,0
> 8,0
> 9,0
> <truncated>
>
> as well as 1360 frames which came in with a negative CONTENTION_TIME.
>
> Ignoring the fact that some frames are coming up with a negative
> CONTENTION_TIME (which potentially points to another problem), what is being
> observed here is that CW_MIN appears to start at 7, rather than the 15 which
> it should be.
>
> I'm just wondering if anyone would have any idea why this is occurring?
>
> Thanks,
>
> --
> Jonathan Guerin
>

What is your time refference ? Are the 2 stations synced to a point
you can have such great accuracy ?


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [ath5k-devel] [support] ath5k contention windows

[Jonathan Guerin]

On Wed, Sep 15, 2010 at 8:48 AM, Nick Kossifidis <mickflemm@gmail.com> wrote:
> 2010/9/14 Jonathan Guerin <jonathan@guerin.id.au>:
>> Hi all,
>>
>> I have some behaviour I'm observing with some Atheros cards we use that
>> doesn't seem to match what the initvals of ath5k are set up to. These are
>> the cards I used:
>> http://www.mini-box.com/s.nl/it.A/id.387/.f
>>
>> I have run a saturated iPerf flow on a conducted testbed with both stations
>> being inside RF-shielding boxes. They are set to 802.11a mode, on channel 1.
>> I then parse the trace, looking for ACK-DATA pairs, and calculating the time
>> difference between them. From this, I remove the TX_TIME of the DATA frame,
>> as well as a DIFS:
>>
>> ACK_TIMESTAMP + DIFS + CONTENTION_TIME + DATA_TX_TIME = DATA_TIMESTAMP
>>
>> which will leave me with the CONTENTION_TIME. Dividing this time by a
>> SLOT_TIME will give me the slot which was chosen by the hardware.
>>
>>
>> According to the driver, in ath5k.h:
>>
>> #define AR5K_TUNE_CWMIN                15
>>
>> CWMIN is initialised to 15.
>>
>> The actual distribution of contention slots I'm observing resembles this:
>>
>> Slot Number,Count
>> 0,1315
>> 1,1302
>> 2,1249
>> 3,1291
>> 4,1347
>> 5,1219
>> 6,1249
>> 7,0
>> 8,0
>> 9,0
>> <truncated>
>>
>> as well as 1360 frames which came in with a negative CONTENTION_TIME.
>>
>> Ignoring the fact that some frames are coming up with a negative
>> CONTENTION_TIME (which potentially points to another problem), what is being
>> observed here is that CW_MIN appears to start at 7, rather than the 15 which
>> it should be.
>>
>> I'm just wondering if anyone would have any idea why this is occurring?
>>
>> Thanks,
>>
>> --
>> Jonathan Guerin
>>
>
> What is your time refference ? Are the 2 stations synced to a point
> you can have such great accuracy ?

I'm capturing using a third-party station. I've had to use a Madwifi
station, as ath5k throws a lot of spurious timestamps up, which make
calculating this very, very difficult.

>
>
> --
> GPG ID: 0xD21DB2DB
> As you read this post global entropy rises. Have Fun ;-)
> Nick
>

Thanks,

--
Jonathan Guerin

Re: [ath5k-devel] [support] ath5k contention windows

[Jonathan Guerin]

On Wed, Sep 15, 2010 at 3:39 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Tue, Sep 14, 2010 at 1:51 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
>> as well as 1360 frames which came in with a negative CONTENTION_TIME.
>>
>> Ignoring the fact that some frames are coming up with a negative
>> CONTENTION_TIME (which potentially points to another problem)
>
> How negative are these?  Are you subtracting more for, say, txtime
> than you should be?

Actually, I've found that they were exactly one slot time negative
(give or take 1us). That said, I was doing these calculations using
the 802.11a OFDM spec timings. I looked at the driver and realised
that SIFS is actually being initialised to 14us, whereas it should be
set to 16us. This will also affect DIFS. Once I take these into
consideration, they come up as approximately 4-5us out. Now that I
think about it, it could make sense.

With regards to the tx_time, I'm using the OFDM tx_time formula from
the 802.11-2007 spec. I'm trying to lock down enough aspects of the
timing in order to verify it. From what I've seen now, my txtime is
almost always 4us short, but I can't work out why. I will get the code
for the txtime when I get into my office, I don't have it on this PC.

>
> --
> Bob Copeland %% www.bobcopeland.com
>

Thanks,

Jonathan

Re: [ath5k-devel] [support] ath5k contention windows

[Jonathan Guerin]

On Wed, Sep 15, 2010 at 9:07 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
> On Wed, Sep 15, 2010 at 3:39 AM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Tue, Sep 14, 2010 at 1:51 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
>>> as well as 1360 frames which came in with a negative CONTENTION_TIME.
>>>
>>> Ignoring the fact that some frames are coming up with a negative
>>> CONTENTION_TIME (which potentially points to another problem)
>>
>> How negative are these?  Are you subtracting more for, say, txtime
>> than you should be?
>
> Actually, I've found that they were exactly one slot time negative
> (give or take 1us). That said, I was doing these calculations using
> the 802.11a OFDM spec timings. I looked at the driver and realised
> that SIFS is actually being initialised to 14us, whereas it should be
> set to 16us. This will also affect DIFS. Once I take these into
> consideration, they come up as approximately 4-5us out. Now that I
> think about it, it could make sense.
>
> With regards to the tx_time, I'm using the OFDM tx_time formula from
> the 802.11-2007 spec. I'm trying to lock down enough aspects of the
> timing in order to verify it. From what I've seen now, my txtime is
> almost always 4us short, but I can't work out why. I will get the code
> for the txtime when I get into my office, I don't have it on this

The timings I used were from the 802.11-2007 spec.
SIFS, DIFS & Slot Time: Table 17-15—OFDM PHY characteristics
NDPS values: Table 17-3—Modulation-dependent parameters
txtime calculations: Section 17.4.3 OFDM TXTIME calculation

Here are the functions I use to do the basics:
int16_t ndbps(uint8_t rate_Mbps)
{
  //Radiotap returns rate in 500kbps units
  rate_Mbps/=2;

   static const uint8_t rate_nsyms[][2] = {
      {  6,  24 },
      {  9,  36 },
      { 12,  48 },
      { 18,  72 },
      { 24,  96 },
      { 36, 144 },
      { 48, 192 },
      { 54, 216 }
   };
   static const size_t nof_rate_nsyms = sizeof(rate_nsyms) /
sizeof(rate_nsyms[0]);
   for(size_t i = 0; i < nof_rate_nsyms; ++i) {
      if(rate_Mbps == rate_nsyms[i][0]) {
         return rate_nsyms[i][1];
      }
   }
   return -1;
}

int getTXTime(int rate, int noctets) {
  uint16_t usecs = 0;
  const int16_t nof_bps = ndbps(rate);

  int chan_rate = 1;

  if(-1 != nof_bps) {
    const uint16_t preamble = 16 * chan_rate;
    const uint16_t signal = 4 * chan_rate;
    const uint16_t tsym = 4 * chan_rate;
    const uint16_t nsyms = ceill((16.0 + 8.0 * (noctets) + 6.0) / nof_bps);
    usecs = preamble + signal + tsym * nsyms;
  }

  return(usecs);
}
>
>>
>> --
>> Bob Copeland %% www.bobcopeland.com
>>
>
> Thanks,
>
> Jonathan
>

Thanks,


--
Jonathan Guerin

Re: [ath5k-devel] [support] ath5k contention windows

[Bruno Randolf]

On Wed September 15 2010 08:07:36 Jonathan Guerin wrote:
> I'm capturing using a third-party station. I've had to use a Madwifi
> station, as ath5k throws a lot of spurious timestamps up, which make
> calculating this very, very difficult.

ah, that's interesting and something we should check, too...

> Actually, I've found that they were exactly one slot time negative
> (give or take 1us). That said, I was doing these calculations using
> the 802.11a OFDM spec timings. I looked at the driver and realised
> that SIFS is actually being initialised to 14us, whereas it should be
> set to 16us. This will also affect DIFS. Once I take these into
> consideration, they come up as approximately 4-5us out. Now that I
> think about it, it could make sense.

hmm, we have a function ath5k_hw_get_default_sifs() which returns 16 for 
802.11a, but it's not used for setting the IFS...

also i think current ath5k_hw_reset_tx_queue() is buggy and sets the AIFS 
wrongly. it uses ah->ah_aifs + tq->tqi_aifs which is 2 + AR5K_TXQ_USEDEFAULT 
which results in 2 + (-1). that does not make sense to me and i will post a 
patch fixing up some of that confusion (but not the SIFS issue) today.

bruno

Re: [ath5k-devel] [support] ath5k contention windows

[Jonathan Guerin]

On Wed, Sep 15, 2010 at 10:58 AM, Bruno Randolf <br1@einfach.org> wrote:
> On Wed September 15 2010 08:07:36 Jonathan Guerin wrote:
>> I'm capturing using a third-party station. I've had to use a Madwifi
>> station, as ath5k throws a lot of spurious timestamps up, which make
>> calculating this very, very difficult.
>
> ah, that's interesting and something we should check, too...
>
>> Actually, I've found that they were exactly one slot time negative
>> (give or take 1us). That said, I was doing these calculations using
>> the 802.11a OFDM spec timings. I looked at the driver and realised
>> that SIFS is actually being initialised to 14us, whereas it should be
>> set to 16us. This will also affect DIFS. Once I take these into
>> consideration, they come up as approximately 4-5us out. Now that I
>> think about it, it could make sense.
>
> hmm, we have a function ath5k_hw_get_default_sifs() which returns 16 for
> 802.11a, but it's not used for setting the IFS...
>
> also i think current ath5k_hw_reset_tx_queue() is buggy and sets the AIFS
> wrongly. it uses ah->ah_aifs + tq->tqi_aifs which is 2 + AR5K_TXQ_USEDEFAULT
> which results in 2 + (-1). that does not make sense to me and i will post a
> patch fixing up some of that confusion (but not the SIFS issue) today.

I'm getting these values from: initval.c
/* Initial mode-specific settings for AR5212 (Written before ar5212_ini) */
static const struct ath5k_ini_mode ar5212_ini_mode_start[] = {
<...>
	{ AR5K_DCU_GBL_IFS_SIFS,
	/*	a/XR	   aTurbo	  b	   g (DYN)     gTurbo     */
	   { 0x00000230, 0x000001e0, 0x000000b0, 0x00000160, 0x000001e0 } },
	{ AR5K_DCU_GBL_IFS_SLOT,
	   { 0x00000168, 0x000001e0, 0x000001b8, 0x0000018c, 0x000001e0 } },
<...>

The IFS_SLOT time is correct:
0x168/0x28 (clock multiplier) = 9us

SIFS is coming up short:
ox230/0x28 = 14us

I assume that the card calculates the DIFS from these two values, as
described in Section 9.2.10 DCF timing relations in the spec?

By the way, I may be completely wrong about some of these things, I'm
just going off the understanding I have regarding the register values.

>
> bruno
>

Thanks for looking into this!

Jonathan

Re: [ath5k-devel] [support] ath5k contention windows

[Bruno Randolf]

On Wed September 15 2010 09:44:09 Jonathan Guerin wrote:
> The timings I used were from the 802.11-2007 spec.
> SIFS, DIFS & Slot Time: Table 17-15—OFDM PHY characteristics
> NDPS values: Table 17-3—Modulation-dependent parameters
> txtime calculations: Section 17.4.3 OFDM TXTIME calculation
> 
> Here are the functions I use to do the basics:
> int16_t ndbps(uint8_t rate_Mbps)
> {
>   //Radiotap returns rate in 500kbps units
>   rate_Mbps/=2;
> 
>    static const uint8_t rate_nsyms[][2] = {
>       {  6,  24 },
>       {  9,  36 },
>       { 12,  48 },
>       { 18,  72 },
>       { 24,  96 },
>       { 36, 144 },
>       { 48, 192 },
>       { 54, 216 }

this is rate * 4

>    };
>    static const size_t nof_rate_nsyms = sizeof(rate_nsyms) /
> sizeof(rate_nsyms[0]);
>    for(size_t i = 0; i < nof_rate_nsyms; ++i) {
>       if(rate_Mbps == rate_nsyms[i][0]) {
>          return rate_nsyms[i][1];
>       }
>    }
>    return -1;
> }
> 
> int getTXTime(int rate, int noctets) {
>   uint16_t usecs = 0;
>   const int16_t nof_bps = ndbps(rate);
> 
>   int chan_rate = 1;
> 
>   if(-1 != nof_bps) {
>     const uint16_t preamble = 16 * chan_rate;
>     const uint16_t signal = 4 * chan_rate;
>     const uint16_t tsym = 4 * chan_rate;
>     const uint16_t nsyms = ceill((16.0 + 8.0 * (noctets) + 6.0) / nof_bps);
>     usecs = preamble + signal + tsym * nsyms;
>   }
> 
>   return(usecs);

if you compare that to the code in mac80211/util.c ieee80211_frame_duration():

		dur = 16; /* SIFS + signal ext */
		dur += 16; /* 17.3.2.3: T_PREAMBLE = 16 usec */
		dur += 4; /* 17.3.2.3: T_SIGNAL = 4 usec */
		dur += 4 * DIV_ROUND_UP((16 + 8 * (len + 4) + 6) * 10,
					4 * rate); /* T_SYM x N_SYM */

it is equivalent, except that you don't add 16 /* SIFS + signal ext */. is 
this intended?

bruno

Re: [ath5k-devel] [support] ath5k contention windows

[Jonathan Guerin]

On Wed, Sep 15, 2010 at 11:47 AM, Bruno Randolf <br1@einfach.org> wrote:
> On Wed September 15 2010 09:44:09 Jonathan Guerin wrote:
>> The timings I used were from the 802.11-2007 spec.
>> SIFS, DIFS & Slot Time: Table 17-15—OFDM PHY characteristics
>> NDPS values: Table 17-3—Modulation-dependent parameters
>> txtime calculations: Section 17.4.3 OFDM TXTIME calculation
>>
>> Here are the functions I use to do the basics:
>> int16_t ndbps(uint8_t rate_Mbps)
>> {
>>   //Radiotap returns rate in 500kbps units
>>   rate_Mbps/=2;
>>
>>    static const uint8_t rate_nsyms[][2] = {
>>       {  6,  24 },
>>       {  9,  36 },
>>       { 12,  48 },
>>       { 18,  72 },
>>       { 24,  96 },
>>       { 36, 144 },
>>       { 48, 192 },
>>       { 54, 216 }
>
> this is rate * 4
>
>>    };
>>    static const size_t nof_rate_nsyms = sizeof(rate_nsyms) /
>> sizeof(rate_nsyms[0]);
>>    for(size_t i = 0; i < nof_rate_nsyms; ++i) {
>>       if(rate_Mbps == rate_nsyms[i][0]) {
>>          return rate_nsyms[i][1];
>>       }
>>    }
>>    return -1;
>> }
>>
>> int getTXTime(int rate, int noctets) {
>>   uint16_t usecs = 0;
>>   const int16_t nof_bps = ndbps(rate);
>>
>>   int chan_rate = 1;
>>
>>   if(-1 != nof_bps) {
>>     const uint16_t preamble = 16 * chan_rate;
>>     const uint16_t signal = 4 * chan_rate;
>>     const uint16_t tsym = 4 * chan_rate;
>>     const uint16_t nsyms = ceill((16.0 + 8.0 * (noctets) + 6.0) / nof_bps);
>>     usecs = preamble + signal + tsym * nsyms;
>>   }
>>
>>   return(usecs);
>
> if you compare that to the code in mac80211/util.c ieee80211_frame_duration():
>
>                dur = 16; /* SIFS + signal ext */
>                dur += 16; /* 17.3.2.3: T_PREAMBLE = 16 usec */
>                dur += 4; /* 17.3.2.3: T_SIGNAL = 4 usec */
>                dur += 4 * DIV_ROUND_UP((16 + 8 * (len + 4) + 6) * 10,
>                                        4 * rate); /* T_SYM x N_SYM */
>
> it is equivalent, except that you don't add 16 /* SIFS + signal ext */. is
> this intended?

Yes, I add the SIFS later when I calculate a full DATA+ACK exchange
for other works, hence why this function does not include it. What is
signal ext there? SIFS should already be 16 on its own...

>
> bruno
>

Thanks,

Jonathan

Re: [ath5k-devel] [support] ath5k contention windows

[Bob Copeland]

On Wed, Sep 15, 2010 at 11:06:21AM +1000, Jonathan Guerin wrote:
> > also i think current ath5k_hw_reset_tx_queue() is buggy and sets the AIFS
> > wrongly. it uses ah->ah_aifs + tq->tqi_aifs which is 2 + AR5K_TXQ_USEDEFAULT
> > which results in 2 + (-1). that does not make sense to me and i will post a
> > patch fixing up some of that confusion (but not the SIFS issue) today.
> 
> SIFS is coming up short:
> ox230/0x28 = 14us

Just a wild guess, driver may include a small fudge factor to account
for time spent in qcu.  At one point I compared all of the initvals
to those from the HAL; we're at least bug-compatible with it if there
are errors here.
 
> By the way, I may be completely wrong about some of these things, I'm
> just going off the understanding I have regarding the register values.

Well mostly no one has looked at them, so you may well have found
some problems.

FWIW if you use coverage classes (not default), we appear to use the
right values there.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [support] ath5k contention windows

[Jonathan Guerin]

On Wed, Sep 15, 2010 at 1:04 PM, Bob Copeland <me@bobcopeland.com> wrote:
>
> Just a wild guess, driver may include a small fudge factor to account
> for time spent in qcu.  At one point I compared all of the initvals
> to those from the HAL; we're at least bug-compatible with it if there
> are errors here.

But, the SIFS and SLOT_TIME values should already account for those times?

>From the spec (Section 9.2.10 DCF timing relations):
aSIFSTime is:	aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay +
aRxTxTurnaroundTime.
aSlotTime is:	aCCATime + aRxTxTurnaroundTime + aAirPropagationTime +
aMACProcessingDelay.

>
>> By the way, I may be completely wrong about some of these things, I'm
>> just going off the understanding I have regarding the register values.
>
> Well mostly no one has looked at them, so you may well have found
> some problems.
>
> FWIW if you use coverage classes (not default), we appear to use the
> right values there.

I'm going to plead ignorance here and say that I'm not sure what you
mean by coverage classes...

>
> --
> Bob Copeland %% www.bobcopeland.com
>
> _______________________________________________
> ath5k-devel mailing list
> ath5k-devel@lists.ath5k.org
> https://lists.ath5k.org/mailman/listinfo/ath5k-devel
>

Re: [support] ath5k contention windows

[Jonathan Guerin]

On Tue, Sep 14, 2010 at 3:53 PM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
> Hi all,
>
> I have some behaviour I'm observing with some Atheros cards we use
> that doesn't seem to match what the initvals of ath5k are set up to.
> These are the cards I used:
> http://www.mini-box.com/s.nl/it.A/id.387/.f
>
> I have run a saturated iPerf flow on a conducted testbed with both
> stations being inside RF-shielding boxes. They are set to 802.11a
> mode, on channel 1. I then parse the trace, looking for ACK-DATA
> pairs, and calculating the time difference between them. From this, I
> remove the TX_TIME of the DATA frame, as well as a DIFS:
>
> ACK_TIMESTAMP + DIFS + CONTENTION_TIME + DATA_TX_TIME = DATA_TIMESTAMP
>
> which will leave me with the CONTENTION_TIME. Dividing this time by a
> SLOT_TIME will give me the slot which was chosen by the hardware.
>
>
> According to the driver, in ath5k.h:
>
> #define AR5K_TUNE_CWMIN                15
>
> CWMIN is initialised to 15.
>
> The actual distribution of contention slots I'm observing resembles this:
>
> Slot Number,Count
> 0,1315
> 1,1302
> 2,1249
> 3,1291
> 4,1347
> 5,1219
> 6,1249
> 7,0
> 8,0
> 9,0
> <truncated>
>
> as well as 1360 frames which came in with a negative CONTENTION_TIME.
>
> Ignoring the fact that some frames are coming up with a negative
> CONTENTION_TIME (which potentially points to another problem), what is
> being observed here is that CW_MIN appears to start at 7, rather than
> the 15 which it should be.
>
> I'm just wondering if anyone would have any idea why this is occurring?

Sorry to bring the post back on topic, I'm just trying to narrow down
what the driver is doing with the CW_MIN and CW_MAX parameters.

$$ ath5k.h
#define AR5K_TUNE_CWMIN				15
#define AR5K_TUNE_CWMIN_11B			31
#define AR5K_TUNE_CWMIN_XR			3
#define AR5K_TUNE_CWMAX				1023
#define AR5K_TUNE_CWMAX_11B			1023
#define AR5K_TUNE_CWMAX_XR			7

$$ qcu.c
/*
 * Set DFS properties for a transmit queue on DCU
 */
int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
{
<... truncated ...>
	/*
	 * Calculate cwmin/max by channel mode
	 */
	cw_min = ah->ah_cw_min = AR5K_TUNE_CWMIN;
	cw_max = ah->ah_cw_max = AR5K_TUNE_CWMAX;
	ah->ah_aifs = AR5K_TUNE_AIFS;
	/*XR is only supported on 5212*/
	if (IS_CHAN_XR(ah->ah_current_channel) &&
			ah->ah_version == AR5K_AR5212) {
		cw_min = ah->ah_cw_min = AR5K_TUNE_CWMIN_XR;
		cw_max = ah->ah_cw_max = AR5K_TUNE_CWMAX_XR;
		ah->ah_aifs = AR5K_TUNE_AIFS_XR;
	/*B mode is not supported on 5210*/
	} else if (IS_CHAN_B(ah->ah_current_channel) &&
			ah->ah_version != AR5K_AR5210) {
		cw_min = ah->ah_cw_min = AR5K_TUNE_CWMIN_11B;
		cw_max = ah->ah_cw_max = AR5K_TUNE_CWMAX_11B;
		ah->ah_aifs = AR5K_TUNE_AIFS_11B;
	}

	cw_min = 1;
	while (cw_min < ah->ah_cw_min)
		cw_min = (cw_min << 1) | 1;

	cw_min = tq->tqi_cw_min < 0 ? (cw_min >> (-tq->tqi_cw_min)) :
		((cw_min << tq->tqi_cw_min) + (1 << tq->tqi_cw_min) - 1);
	cw_max = tq->tqi_cw_max < 0 ? (cw_max >> (-tq->tqi_cw_max)) :
		((cw_max << tq->tqi_cw_max) + (1 << tq->tqi_cw_max) - 1);
<... truncated ...>
}

$$ attach.c
int ath5k_hw_attach(struct ath5k_softc *sc)
{
<... truncated ...>
	/*
	 * HW information
	 */
	ah->ah_radar.r_enabled = AR5K_TUNE_RADAR_ALERT;
	ah->ah_turbo = false;
	ah->ah_txpower.txp_tpc = AR5K_TUNE_TPC_TXPOWER;
	ah->ah_imr = 0;
	ah->ah_atim_window = 0;
	ah->ah_aifs = AR5K_TUNE_AIFS;
	ah->ah_cw_min = AR5K_TUNE_CWMIN;
<... truncated ...>
}

I'm trying to understand where the CW_MIN value is being set. My
understanding is that if the hardware is in 802.11a (non-turbo) mode,
it will be set to AR5K_TUNE_CWMIN, both when it is attached, and when
the queue is reset.

Is there anywhere else that this value might be overridden and explain
the behaviour I'm observing? I can see a few places where the queues
are initilised to AR5K_TXQ_USEDEFAULT - does this make the card pull
the value from the ah->ah_cw_min variable?


>
> Thanks,
>
> --
> Jonathan Guerin

Re: [ath5k-devel] [support] ath5k contention windows

[Bruno Randolf]

On Wed September 15 2010 12:40:36 Jonathan Guerin wrote:
> On Tue, Sep 14, 2010 at 3:53 PM, Jonathan Guerin <jonathan@guerin.id.au> 
wrote:
> > Hi all,
> > 
> > I have some behaviour I'm observing with some Atheros cards we use
> > that doesn't seem to match what the initvals of ath5k are set up to.
> > These are the cards I used:
> > http://www.mini-box.com/s.nl/it.A/id.387/.f
> > 
> > I have run a saturated iPerf flow on a conducted testbed with both
> > stations being inside RF-shielding boxes. They are set to 802.11a
> > mode, on channel 1. I then parse the trace, looking for ACK-DATA
> > pairs, and calculating the time difference between them. From this, I
> > remove the TX_TIME of the DATA frame, as well as a DIFS:
> > 
> > ACK_TIMESTAMP + DIFS + CONTENTION_TIME + DATA_TX_TIME = DATA_TIMESTAMP
> > 
> > which will leave me with the CONTENTION_TIME. Dividing this time by a
> > SLOT_TIME will give me the slot which was chosen by the hardware.
> > 
> > 
> > According to the driver, in ath5k.h:
> > 
> > #define AR5K_TUNE_CWMIN                15
> > 
> > CWMIN is initialised to 15.
> > 
> > The actual distribution of contention slots I'm observing resembles this:
> > 
> > Slot Number,Count
> > 0,1315
> > 1,1302
> > 2,1249
> > 3,1291
> > 4,1347
> > 5,1219
> > 6,1249
> > 7,0
> > 8,0
> > 9,0
> > <truncated>
> > 
> > as well as 1360 frames which came in with a negative CONTENTION_TIME.
> > 
> > Ignoring the fact that some frames are coming up with a negative
> > CONTENTION_TIME (which potentially points to another problem), what is
> > being observed here is that CW_MIN appears to start at 7, rather than
> > the 15 which it should be.
> > 
> > I'm just wondering if anyone would have any idea why this is occurring?
> 
> Sorry to bring the post back on topic, I'm just trying to narrow down
> what the driver is doing with the CW_MIN and CW_MAX parameters.
> 
> $$ ath5k.h
> #define AR5K_TUNE_CWMIN				15
> #define AR5K_TUNE_CWMIN_11B			31
> #define AR5K_TUNE_CWMIN_XR			3
> #define AR5K_TUNE_CWMAX				1023
> #define AR5K_TUNE_CWMAX_11B			1023
> #define AR5K_TUNE_CWMAX_XR			7
> 
> $$ qcu.c
> /*
>  * Set DFS properties for a transmit queue on DCU
>  */
> int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
> {
> <... truncated ...>
> 	/*
> 	 * Calculate cwmin/max by channel mode
> 	 */
> 	cw_min = ah->ah_cw_min = AR5K_TUNE_CWMIN;
> 	cw_max = ah->ah_cw_max = AR5K_TUNE_CWMAX;
> 	ah->ah_aifs = AR5K_TUNE_AIFS;
> 	/*XR is only supported on 5212*/
> 	if (IS_CHAN_XR(ah->ah_current_channel) &&
> 			ah->ah_version == AR5K_AR5212) {
> 		cw_min = ah->ah_cw_min = AR5K_TUNE_CWMIN_XR;
> 		cw_max = ah->ah_cw_max = AR5K_TUNE_CWMAX_XR;
> 		ah->ah_aifs = AR5K_TUNE_AIFS_XR;
> 	/*B mode is not supported on 5210*/
> 	} else if (IS_CHAN_B(ah->ah_current_channel) &&
> 			ah->ah_version != AR5K_AR5210) {
> 		cw_min = ah->ah_cw_min = AR5K_TUNE_CWMIN_11B;
> 		cw_max = ah->ah_cw_max = AR5K_TUNE_CWMAX_11B;
> 		ah->ah_aifs = AR5K_TUNE_AIFS_11B;
> 	}
> 
> 	cw_min = 1;
> 	while (cw_min < ah->ah_cw_min)
> 		cw_min = (cw_min << 1) | 1;
> 
> 	cw_min = tq->tqi_cw_min < 0 ? (cw_min >> (-tq->tqi_cw_min)) :
> 		((cw_min << tq->tqi_cw_min) + (1 << tq->tqi_cw_min) - 1);
> 	cw_max = tq->tqi_cw_max < 0 ? (cw_max >> (-tq->tqi_cw_max)) :
> 		((cw_max << tq->tqi_cw_max) + (1 << tq->tqi_cw_max) - 1);
> <... truncated ...>
> }
> 
> $$ attach.c
> int ath5k_hw_attach(struct ath5k_softc *sc)
> {
> <... truncated ...>
> 	/*
> 	 * HW information
> 	 */
> 	ah->ah_radar.r_enabled = AR5K_TUNE_RADAR_ALERT;
> 	ah->ah_turbo = false;
> 	ah->ah_txpower.txp_tpc = AR5K_TUNE_TPC_TXPOWER;
> 	ah->ah_imr = 0;
> 	ah->ah_atim_window = 0;
> 	ah->ah_aifs = AR5K_TUNE_AIFS;
> 	ah->ah_cw_min = AR5K_TUNE_CWMIN;
> <... truncated ...>
> }
> 
> I'm trying to understand where the CW_MIN value is being set. My
> understanding is that if the hardware is in 802.11a (non-turbo) mode,
> it will be set to AR5K_TUNE_CWMIN, both when it is attached, and when
> the queue is reset.
> 
> Is there anywhere else that this value might be overridden and explain
> the behaviour I'm observing? I can see a few places where the queues
> are initilised to AR5K_TXQ_USEDEFAULT - does this make the card pull
> the value from the ah->ah_cw_min variable?

hey, yes this is completey fcked up, weird and even wrong. as i said i'll post 
a patch to that today, soon... better to wait with your review until that.

bruno