2010/9/14 Jonathan Guerin <[email protected]>:
> 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
On Wed, Sep 15, 2010 at 10:58 AM, Bruno Randolf <[email protected]> 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
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
On Wed, Sep 15, 2010 at 1:04 PM, Bob Copeland <[email protected]> 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 %% http://www.bobcopeland.com
>
> _______________________________________________
> ath5k-devel mailing list
> [email protected]
> https://lists.ath5k.org/mailman/listinfo/ath5k-devel
>
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 %% http://www.bobcopeland.com
On Wed, Sep 15, 2010 at 8:48 AM, Nick Kossifidis <[email protected]> wrote:
> 2010/9/14 Jonathan Guerin <[email protected]>:
>> 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