On Thu, Nov 25, 2010 at 8:41 AM, Jonathan Guerin <jonathan@xxxxxxxxxxxx> wrote:
> On Wed, Nov 24, 2010 at 10:55 PM, Nick Kossifidis <mickflemm@xxxxxxxxx> wrote:
>> 2010/11/24 Jonathan Guerin <jonathan@xxxxxxxxxxxx>:
>>>
>>>> diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
>>>> index e691378..4556f29 100644
>>>> --- a/drivers/net/wireless/ath/ath5k/pcu.c
>>>> +++ b/drivers/net/wireless/ath/ath5k/pcu.c
>>>> @@ -763,7 +763,7 @@ ath5k_hw_check_beacon_timers(struct ath5k_hw *ah, int intval)
>>>> * @ah: The &struct ath5k_hw
>>>> * @coverage_class: IEEE 802.11 coverage class number
>>>> *
>>>> - * Sets slot time, ACK timeout and CTS timeout for given coverage class.
>>>> + * Sets IFS intervals and ACK/CTS timeouts for given coverage class.
>>>> */
>>>> void ath5k_hw_set_coverage_class(struct ath5k_hw *ah, u8 coverage_class)
>>>> {
>>>> @@ -772,7 +772,7 @@ void ath5k_hw_set_coverage_class(struct ath5k_hw *ah, u8 coverage_class)
>>>> int ack_timeout = ath5k_hw_get_default_sifs(ah) + slot_time;
>>>
>>> This is not quite right:
>>>
>>> According to the 802.11-2007 spec document, the ACKTimeout value is
>>> (Section 9.2.8 ACK procedure):
>>> ACKTimeout = aSIFSTime + aSlotTime + aPHY-RX-START-Delay
>>>
>>> From Table 17-15--OFDM PHY characteristics, the values are:
>>> aSIFSTime = 16
>>> aSlotTime = 9
>>> aPHY-RX-START-Delay = 25
>>>
>>> Therefore, ACKTimeout = 50
>>>
>>> Ignoring my uniformed comments from before, this is the only thing I
>>> can see that's wrong.
>>>
>>> Cheers,
>>>
>>> Jonathan
>>
>> Hmm I didn't mess with set_coverage_class so i didn't look up for ack
>> timeout. That phy-rx-start-delay is standard value or hw specific ?
>> Also does it change with clockrate (bwmodes) ? We already have a phy
>> activation -> rx start delay (check patch 25). It's 10.000 on RF5111
>> and 2.000 on RF5112 and later, if we divide by A clock it's 250 on
>> RF5111 and 50 on RF5112 and later. Do you think it's related ?
>
> The phy-rx-start-delay is set in the standard. I'll find you the
> relevant pages soon.
The aPHY-RX-START-Delay value is specific per PHY. In the case of
OFDM, you can find the relevant timings at:
Table 17-15--OFDM PHY characteristics
aPHY-RX-START-Delay 25 μs (20MHz) 49 μs (10MHz) 97 μs (5MHz)
>
> I'll look up the others tomorrow. I'm feeling pretty sick today, so
> not sure if I'll get a chance.
I just a quick look at the code. The first thing that pops to mind and
that is apparent in the Table mentioned above, you can't just multiply
by 2 every time you halve the channel - the value is actually slightly
shorter than this.
Secondly, I'm assuming that the AR5K_PHY_RX_DELAY register refers to
the aPHY-RX-START-Delay value from the standard. It would make sense
that the card require this value, as it is necessary in resetting the
NAV (9.2.5.4 Setting and resetting the NAV), for CTS timeouts (9.2.5.7
CTS procedure), & ACK Timeouts (9.2.8 ACK procedure). The first 2
cases both refer to station behaviour after an RTS frame, but are
slightly different in that one is from an overhearing station, whereas
the the second is from the sending station. In the driver, which case
is the CTSTimeout value used for?
Cheers,
Jonathan
>
> Cheers,
>
> Jonathan
>
>>
>> --
>> GPG ID: 0xD21DB2DB
>> As you read this post global entropy rises. Have Fun ;-)
>> Nick
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
