[ath9k-devel] ath9k driver modifications

[ath9k-devel] ath9k driver modifications

[Mikkel Hagen]

Hello,
     I work with the UNH-IOL to test conformance of 11n MAC, we have 
been trying to implement our test suite over an atheros 11n card. We 
have most of the test suite working except for two issues that are 
preventing us finishing the implementation:
1. turning off retries
2. setting a hard rate on transmit


We tried to use iwconfig to set retry and rates but it seems to ignore 
those settings, we then tried to use the radiotap header to no success, 
we then tried to start modifying the atheros drivers and still did not 
meet with much success.  We are using lorcon over the mac80211 driver 
for injection, with the ath9k driver.  Right  now we have been modifying 
the driver in the 3.5 kernel, but we can use any version that you recommend.

An example of something that we have already tried to not transmit 
retries is below, from xmit.c, line 316:

hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_RETRY);

to

hdr->frame_control |= cpu_to_le16(0x0000);

To try and force it not to set the retry bit, but this did not seem to 
do anything.  Do you have any pointers on what we might try next?  Thanks!

-- 
Mikkel Hagen
Research and Development
Data Center Bridging/FC/Wireless/SAS/SATA/OFA/iWARP Consortiums
Phone:1-603-862-0701 Fax:1-603-862-4181
UNH-IOL
121 Technology Drive, Suite 2
Durham, NH 03824
Facebook <http://www.facebook.com/UNHIOL> Twitter 
<http://twitter.com/unh_iol>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130314/db1d3289/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FBIcon.png
Type: image/png
Size: 10425 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130314/db1d3289/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Twitter-Icon.png
Type: image/png
Size: 12064 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130314/db1d3289/attachment-0003.png 

[ath9k-devel] ath9k driver modifications

[Adrian Chadd]

Hi,


On 14 March 2013 09:22, Mikkel Hagen <mhagen@iol.unh.edu> wrote:

>  Hello,
>     I work with the UNH-IOL to test conformance of 11n MAC, we have been
> trying to implement our test suite over an atheros 11n card.   We have most
> of the test suite working except for two issues that are preventing us
> finishing the implementation:
> 1. turning off retries
> 2. setting a hard rate on transmit
>
>
> We tried to use iwconfig to set retry and rates but it seems to ignore
> those settings, we then tried to use the radiotap header to no success, we
> then tried to start modifying the atheros drivers and still did not meet
> with much success.  We are using lorcon over the mac80211 driver for
> injection, with the ath9k driver.  Right  now we have been modifying the
> driver in the 3.5 kernel, but we can use any version that you recommend.
>
> An example of something that we have already tried to not transmit retries
> is below, from xmit.c, line 316:
>
> hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_RETRY);
>
> to
>
> hdr->frame_control |= cpu_to_le16(0x0000);
>
> To try and force it not to set the retry bit, but this did not seem to do
> anything.  Do you have any pointers on what we might try next?  Thanks!
>
>
>
That only sets the retry bit on outgoing frames, but the driver and
mac80211 will do something different.

You need to find a way to tell mac80211 and the rate control layer to set
the retry count to 1.

The problem is that mac80211/ath9k will do software retransmissions too, so
you may have to extend it to have some way to say "don't software
retransmit this frame either please." Felix would know better about this.

Thanks,



Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130315/d2594cee/attachment.htm 

[ath9k-devel] ath9k driver modifications

[Mikkel Hagen]

Thanks Adrian,
     I appreciate the quick response, we will look into the rate control 
layer and the mac80211 as well and see if we can get this working.  Thanks!

Mikkel Hagen
Research and Development
Data Center Bridging/FC/Wireless/SAS/SATA/OFA/iWARP Consortiums
Phone:1-603-862-0701 Fax:1-603-862-4181
UNH-IOL
121 Technology Drive, Suite 2
Durham, NH 03824
Facebook <http://www.facebook.com/UNHIOL> Twitter 
<http://twitter.com/unh_iol>
On 03/15/2013 04:30 PM, Adrian Chadd wrote:
> Hi,
>
>
> On 14 March 2013 09:22, Mikkel Hagen <mhagen@iol.unh.edu 
> <mailto:mhagen@iol.unh.edu>> wrote:
>
>     Hello,
>         I work with the UNH-IOL to test conformance of 11n MAC, we
>     have been trying to implement our test suite over an atheros 11n
>     card.   We have most of the test suite working except for two
>     issues that are preventing us finishing the implementation:
>     1. turning off retries
>     2. setting a hard rate on transmit
>
>
>     We tried to use iwconfig to set retry and rates but it seems to
>     ignore those settings, we then tried to use the radiotap header to
>     no success, we then tried to start modifying the atheros drivers
>     and still did not meet with much success.  We are using lorcon
>     over the mac80211 driver for injection, with the ath9k driver. 
>     Right  now we have been modifying the driver in the 3.5 kernel,
>     but we can use any version that you recommend.
>
>     An example of something that we have already tried to not transmit
>     retries is below, from xmit.c, line 316:
>
>     hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_RETRY);
>
>     to
>
>     hdr->frame_control |= cpu_to_le16(0x0000);
>
>     To try and force it not to set the retry bit, but this did not
>     seem to do anything.  Do you have any pointers on what we might
>     try next?  Thanks!
>
>
>
> That only sets the retry bit on outgoing frames, but the driver and 
> mac80211 will do something different.
>
> You need to find a way to tell mac80211 and the rate control layer to 
> set the retry count to 1.
>
> The problem is that mac80211/ath9k will do software retransmissions 
> too, so you may have to extend it to have some way to say "don't 
> software retransmit this frame either please." Felix would know better 
> about this.
>
> Thanks,
>
>
>
> Adrian
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130315/50fff6a2/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FBIcon.png
Type: image/png
Size: 10425 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130315/50fff6a2/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Twitter-Icon.png
Type: image/png
Size: 12064 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130315/50fff6a2/attachment-0003.png 

[ath9k-devel] ath9k driver modifications

[Adrian Chadd]

hi,

You're welcome. :0

I think it's worth reviewing what goes on here.

* There's the RETRY bit in the 802.11 header for each frame. It can be set
either by software or by a field in the TX descriptor.
* There's a retry value for each of up to 4 rate configurations in a TX
descriptor. This controls how many times the hardware will try to
retransmit the frame with it failing. This is decided by mac80211 and
ratecontrol. I believe it's the default long/short retry, but I could be
wrong, because;
* There's a short and long retry count configured per DCU:

        /* Set retry limit values */
        OS_REG_WRITE(ah, AR_DRETRY_LIMIT(q),
                   SM(INIT_SSH_RETRY, AR_D_RETRY_LIMIT_STA_SH)
                 | SM(INIT_SLG_RETRY, AR_D_RETRY_LIMIT_STA_LG)
                 | SM(qi->tqi_lgretry, AR_D_RETRY_LIMIT_FR_LG)
                 | SM(qi->tqi_shretry, AR_D_RETRY_LIMIT_FR_SH)
        );

(From FreeBSD - in ath9k it's similar code, just different names of things.)

I'll have to check the datasheets to see what is actually going on here.

Then there's whether you're doing software retransmission. This is done in
the ADDBA enabled path in ath9k/mac80211. I don't know if ath9k/mac80211
does software retry for non-aggregate session frames - I know that FreeBSD
doesn't yet support it but I have almost all of the framework in place.
(Frame ordering is much more of a problem when you're doing software
retransmission without ADDBA enabled.) This is done by mac80211 and ath9k.


On 15 March 2013 14:17, Mikkel Hagen <mhagen@iol.unh.edu> wrote:

>  Thanks Adrian,
>     I appreciate the quick response, we will look into the rate control
> layer and the mac80211 as well and see if we can get this working.  Thanks!
>
>
>  Mikkel Hagen
> Research and Development
> Data Center Bridging/FC/Wireless/SAS/SATA/OFA/iWARP Consortiums
> Phone:1-603-862-0701 Fax:1-603-862-4181
> UNH-IOL
> 121 Technology Drive, Suite 2
> Durham, NH 03824
> [image: Facebook] <http://www.facebook.com/UNHIOL> [image: Twitter]<http://twitter.com/unh_iol>
>  On 03/15/2013 04:30 PM, Adrian Chadd wrote:
>
> Hi,
>
>
> On 14 March 2013 09:22, Mikkel Hagen <mhagen@iol.unh.edu> wrote:
>
>>  Hello,
>>     I work with the UNH-IOL to test conformance of 11n MAC, we have been
>> trying to implement our test suite over an atheros 11n card.   We have most
>> of the test suite working except for two issues that are preventing us
>> finishing the implementation:
>> 1. turning off retries
>> 2. setting a hard rate on transmit
>>
>>
>> We tried to use iwconfig to set retry and rates but it seems to ignore
>> those settings, we then tried to use the radiotap header to no success, we
>> then tried to start modifying the atheros drivers and still did not meet
>> with much success.  We are using lorcon over the mac80211 driver for
>> injection, with the ath9k driver.  Right  now we have been modifying the
>> driver in the 3.5 kernel, but we can use any version that you recommend.
>>
>> An example of something that we have already tried to not transmit
>> retries is below, from xmit.c, line 316:
>>
>> hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_RETRY);
>>
>> to
>>
>> hdr->frame_control |= cpu_to_le16(0x0000);
>>
>> To try and force it not to set the retry bit, but this did not seem to do
>> anything.  Do you have any pointers on what we might try next?  Thanks!
>>
>>
>>
>  That only sets the retry bit on outgoing frames, but the driver and
> mac80211 will do something different.
>
>  You need to find a way to tell mac80211 and the rate control layer to
> set the retry count to 1.
>
>  The problem is that mac80211/ath9k will do software retransmissions too,
> so you may have to extend it to have some way to say "don't software
> retransmit this frame either please." Felix would know better about this.
>
>  Thanks,
>
>
>
> Adrian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130315/8dc6abfd/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12064 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130315/8dc6abfd/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10425 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130315/8dc6abfd/attachment-0003.png