[ath9k-devel] Retry control & iwconfig

[ath9k-devel] Retry control & iwconfig

[Olivier Marce]

Hi there,
I tried to use "retry" command of iwconfig to avoid any retry.
I still see retries on the traces, although it is correclty set (Retry 
limit: 0)

Looking at the list archive I understood that retry command of iwconfig 
does not work or at least it is not possible to avoid all retries (see 
[https://www.mail-archive.com/ath9k-devel%40lists.ath9k.org/msg09951.html]]

Is it correct ?

If so, is there another way to suppress retransmit than by patching the 
firmware ?

Thx
Regards

-- 
Olivier Marc?
Alcatel-Lucent Bell Labs France

[ath9k-devel] Retry control & iwconfig

[Holger Schurig]

1. "iwconfig" is outdated, don't use it. Use "iw" instead
2. As noted in the mail you linked to, the retry is also done by
software in the mac80211 layer and in the ath9k driver
3. ath9k based-cards don't have firmware

So, what you have basically do is to find out where in
drivers/net/wireless/atheros and net/mac80211 or net/wireless the
software-retry handling is taking place and make this switchable. LXR
tells me that IEEE80211_FCTL_RETRY is used in ath9k, see
http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357
. It seems that the ath9k has a max number of retries defined:
http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653

Hope that puts you into the right direction.

[ath9k-devel] Retry control & iwconfig

[abhinav narain]

Hi,
just change value from 10 to 0 for retries to be zero!
http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954

mac80211 API does not update this in ath9k for some reason and the default
value of retries is 7 in rate minstrel which has also to be changed.

Thanks,
Abhinav


On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com>wrote:

> 1. "iwconfig" is outdated, don't use it. Use "iw" instead
> 2. As noted in the mail you linked to, the retry is also done by
> software in the mac80211 layer and in the ath9k driver
> 3. ath9k based-cards don't have firmware
>
> So, what you have basically do is to find out where in
> drivers/net/wireless/atheros and net/mac80211 or net/wireless the
> software-retry handling is taking place and make this switchable. LXR
> tells me that IEEE80211_FCTL_RETRY is used in ath9k, see
>
> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357
> . It seems that the ath9k has a max number of retries defined:
>
> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653
>
> Hope that puts you into the right direction.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140326/b7526b43/attachment.html 

[ath9k-devel] Retry control & iwconfig

[Pradeep Reddy]

Hi Marc,

You can set NO_ACK bit in Tx descriptor of each packet to indicate the 
hardware to not to wait for ACK, which in turn avoids retries for that 
particular packet.

If you set IEEE80211_TX_CTL_NO_ACK flag in tx_ctl information, ath9k 
layer will take care of setting the Tx descriptor flag ATH9K_TXDESC_NOACK.

Regards
Pradeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140327/68392481/attachment.htm 

[ath9k-devel] Retry control & iwconfig

[Olivier Marce]

Hi Pradeep,
thanks, this helped me a lot.
It pointed me out to iw command "set noack_map" that is made to set 
IEEE80211_TX_CTL_NO_ACK flag, and that I did not consider before.

I then used "iw <dev> set noack_map 9" to avoid waiting for ACK  and to 
avoid retries by <dev>.
What I expected was to see almost no difference with noack when the link 
conditions are good (i.e. high RSSI level).
But this is not the case, with noack set, the data transfer is almost 
not possible (I used iperf, and it even does not complete its test, 95 
to 98% lost packet with ping).

What is the reason for this ? Does the NO_ACK bit has an additional 
impact on the device behaviour like not respecting the requested delays 
on the air, or whatever ?
Any idea ?

Thanks.

Olivier.

On 27/03/2014 05:20, Pradeep Reddy wrote:
> Hi Marc,
>
> You can set NO_ACK bit in Tx descriptor of each packet to indicate the
> hardware to not to wait for ACK, which in turn avoids retries for that
> particular packet.
>
> If you set IEEE80211_TX_CTL_NO_ACK flag in tx_ctl information, ath9k
> layer will take care of setting the Tx descriptor flag ATH9K_TXDESC_NOACK.
>
> Regards
> Pradeep
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

-- 
Olivier Marc?
Alcatel-Lucent Bell Labs France

[ath9k-devel] Retry control & iwconfig

[Pradeep Reddy]

Hi Olivier,

NO_ACK feature is meant for few special cases, like,
(i)when you want to inject certain packets (Injector), but doesn't bother whether it is delivered or not,
(ii) In QoS/11n case, where per packet ACK is disabled and Block ACK is enabled
(iii) For boradcast/multicast packets, for which ACK is not needed, For Ex Beacons

As you are aware the purpose of ACK in 802.11 Std is to ensure the data packet is delivered without any errors to intended destination, due to uncertainty nature of Wireless Medium.

In your case, NO_ACK is set, but Rate control algorithm is still decides the rate based on Tx stats and sets number of retries. But since NO_ACK bit is set, h/w won't wait for ACK and doesn't ensure the error-free delivery of data packets to target.

With NO_ACK set also, still the STA follows the CSMA/CA protocol, doesn't violate any protocol timings. I think, your env might be busy with lot of WLAN traffic, so that even with higher signal strengths the packets might not be making till destination as error-free. Is that Correct ?

I think, fixing the data rates to make it behave better.

Let me know how it goes.

Regards
Pradeep

Date: Fri, 28 Mar 2014 17:26:06 +0100
From: Olivier Marce<Olivier.Marce@alcatel-lucent.com>
Subject: Re: [ath9k-devel] Retry control & iwconfig
To:<ath9k-devel@venema.h4ckr.net>
Message-ID:<5335A29E.3010209@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed

Hi Pradeep,
thanks, this helped me a lot.
It pointed me out to iw command "set noack_map" that is made to set
IEEE80211_TX_CTL_NO_ACK flag, and that I did not consider before.

I then used "iw <dev> set noack_map 9" to avoid waiting for ACK  and to
avoid retries by <dev>.
What I expected was to see almost no difference with noack when the link
conditions are good (i.e. high RSSI level).
But this is not the case, with noack set, the data transfer is almost
not possible (I used iperf, and it even does not complete its test, 95
to 98% lost packet with ping).

What is the reason for this ? Does the NO_ACK bit has an additional
impact on the device behaviour like not respecting the requested delays
on the air, or whatever ?
Any idea ?

Thanks.

Olivier.

On 27/03/2014 05:20, Pradeep Reddy wrote:

> Hi Marc,
>
> You can set NO_ACK bit in Tx descriptor of each packet to indicate the
> hardware to not to wait for ACK, which in turn avoids retries for that
> particular packet.
>
> If you set IEEE80211_TX_CTL_NO_ACK flag in tx_ctl information, ath9k
> layer will take care of setting the Tx descriptor flag ATH9K_TXDESC_NOACK.
>
> Regards
> Pradeep

[ath9k-devel] Retry control & iwconfig

[Paul Fuxjaeger]

On 29.03.14 19:32, Pradeep Reddy wrote:
> 
> I think, fixing the data rates to make it behave better.

I think so too, maybe minstrel does something very unclever in context
of NO_ACK being set (like sticking to a very high MCS). Or this is
simply what we get when turning off (fast!) mac-layer retransmission in
a busy environment and using TCP over that very leaky pipe then.

-paul

[ath9k-devel] Retry control & iwconfig

[Olivier Marce]

Hi,
thanks Pradeep and Paul.

I investigated on this.
But as this time, I'm unable to make a link working with no_ack, even if 
I fix the rate.

The environment is crowded, but not so much. With ACK (iw <dev> set 
noack_map 0 to be sure), for a iperf 10 sec long test, I found only 43 
retry packets over 19k TCP packets.

As soon as I set noack (iw <dev> set noack_map 9), the iperf test does 
not work at all. I'm able to see only 2 packets coming from the iperf 
client over 15 seconds of capture.
The same when fixing the rate (iwconfig <dev> rate 11M), the same with 
1M rate.
The capture done at the 2 ends (AP and STA) are consistent.
This is the same with ping, it does not work (98% packet loss)

Other observations :
- the ACK are well transmitted in the 2 directions
- same behaviour if RTS/CTS on or off

Did someone make a link with no_ack work ? In which condition ?

Regards

On 31/03/2014 12:27, Paul Fuxjaeger wrote:
> On 29.03.14 19:32, Pradeep Reddy wrote:
>>
>> I think, fixing the data rates to make it behave better.
>
> I think so too, maybe minstrel does something very unclever in context
> of NO_ACK being set (like sticking to a very high MCS). Or this is
> simply what we get when turning off (fast!) mac-layer retransmission in
> a busy environment and using TCP over that very leaky pipe then.
>
> -paul
>
>

-- 
Olivier Marc?
Alcatel-Lucent Bell Labs France

[ath9k-devel] Retry control & iwconfig

[Olivier Marce]

Hi,
I found that it can work but depends on device used as STA. As I used 
special feature like noack on AP side only, I did not think that STA 
device would be so important in the setup. Then changing the STA makes 
it working.
Not investigated yet why it did not work, I'll let the list know why 
mater (looks that some strange Block Ack policy was sent back by the STA 
toward the AP).
Regards

On 02/04/2014 12:02, Olivier Marce wrote:
> Hi,
> thanks Pradeep and Paul.
>
> I investigated on this.
> But as this time, I'm unable to make a link working with no_ack, even if
> I fix the rate.
>
> The environment is crowded, but not so much. With ACK (iw <dev> set
> noack_map 0 to be sure), for a iperf 10 sec long test, I found only 43
> retry packets over 19k TCP packets.
>
> As soon as I set noack (iw <dev> set noack_map 9), the iperf test does
> not work at all. I'm able to see only 2 packets coming from the iperf
> client over 15 seconds of capture.
> The same when fixing the rate (iwconfig <dev> rate 11M), the same with
> 1M rate.
> The capture done at the 2 ends (AP and STA) are consistent.
> This is the same with ping, it does not work (98% packet loss)
>
> Other observations :
> - the ACK are well transmitted in the 2 directions
> - same behaviour if RTS/CTS on or off
>
> Did someone make a link with no_ack work ? In which condition ?
>
> Regards
>
> On 31/03/2014 12:27, Paul Fuxjaeger wrote:
>> On 29.03.14 19:32, Pradeep Reddy wrote:
>>>
>>> I think, fixing the data rates to make it behave better.
>>
>> I think so too, maybe minstrel does something very unclever in context
>> of NO_ACK being set (like sticking to a very high MCS). Or this is
>> simply what we get when turning off (fast!) mac-layer retransmission in
>> a busy environment and using TCP over that very leaky pipe then.
>>
>> -paul
>>
>>
>

-- 
Olivier Marc?
Alcatel-Lucent Bell Labs France

[ath9k-devel] Retry control & iwconfig

[marcus muffin]

hi all,

I found that there is a retry value in net/wireless/core.c

348         rdev->wiphy.retry_short = 7;
349         rdev->wiphy.retry_long = 4;

If i set those values to 0. the retry will still exist. Is it correct?

Marcus


2014-03-26 21:34 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>:

> Hi,
> just change value from 10 to 0 for retries to be zero!
>
> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954
>
> mac80211 API does not update this in ath9k for some reason and the default
> value of retries is 7 in rate minstrel which has also to be changed.
>
> Thanks,
> Abhinav
>
>
> On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com>wrote:
>
>> 1. "iwconfig" is outdated, don't use it. Use "iw" instead
>> 2. As noted in the mail you linked to, the retry is also done by
>> software in the mac80211 layer and in the ath9k driver
>> 3. ath9k based-cards don't have firmware
>>
>> So, what you have basically do is to find out where in
>> drivers/net/wireless/atheros and net/mac80211 or net/wireless the
>> software-retry handling is taking place and make this switchable. LXR
>> tells me that IEEE80211_FCTL_RETRY is used in ath9k, see
>>
>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357
>> . It seems that the ath9k has a max number of retries defined:
>>
>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653
>>
>> Hope that puts you into the right direction.
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140417/72a1ddb6/attachment.htm 

[ath9k-devel] Retry control & iwconfig

[abhinav narain]

Hi Marcus,
Yes, as I suggested before, you should change it in driver code.
This value in mac80211 codebase is not reflected in ath9k driver(atleast)
where the default is 10 retransmits.
And if someone can explain how does minstrel work with default as 7
retransmits while driver does 10 retransmits,
that will be awesome!

-
Abhinav



On Wed, Apr 16, 2014 at 9:49 PM, marcus muffin <ath9kmuffin@gmail.com>wrote:

> hi all,
>
> I found that there is a retry value in net/wireless/core.c
>
> 348         rdev->wiphy.retry_short = 7;
> 349         rdev->wiphy.retry_long = 4;
>
> If i set those values to 0. the retry will still exist. Is it correct?
>
> Marcus
>
>
> 2014-03-26 21:34 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>:
>
> Hi,
>> just change value from 10 to 0 for retries to be zero!
>>
>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954
>>
>> mac80211 API does not update this in ath9k for some reason and the default
>> value of retries is 7 in rate minstrel which has also to be changed.
>>
>> Thanks,
>> Abhinav
>>
>>
>> On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com>wrote:
>>
>>> 1. "iwconfig" is outdated, don't use it. Use "iw" instead
>>> 2. As noted in the mail you linked to, the retry is also done by
>>> software in the mac80211 layer and in the ath9k driver
>>> 3. ath9k based-cards don't have firmware
>>>
>>> So, what you have basically do is to find out where in
>>> drivers/net/wireless/atheros and net/mac80211 or net/wireless the
>>> software-retry handling is taking place and make this switchable. LXR
>>> tells me that IEEE80211_FCTL_RETRY is used in ath9k, see
>>>
>>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357
>>> . It seems that the ath9k has a max number of retries defined:
>>>
>>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653
>>>
>>> Hope that puts you into the right direction.
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140416/909909bd/attachment.htm 

[ath9k-devel] Retry control & iwconfig

[marcus muffin]

Hi all,

I would like to investigate more on this retry issue. I did a simple
experiment (single link, sender is a computer and receiver is a tp-link
router. Both are with ath9k driver). I hack the code in sender side with as
above mentioned, minstrel (from 7 to 0), ath9k/init.c (from 10 to 0),
net/wireless/core.c (long retry from 4 to 0 and short retry from 7 to 0).

After re-compile, the iwconfig still show the value of long retry is 7. I
am not so sure where the wireless utilities still be able to get this
value. I think there may be some missing part to hack for retry.

With this hack of code, I perform iperf test (udp with 65 mbps for few
minutes), I don't see any tx ecessive retries in iwconfig but the results
of iperf doesn't change. If retry is disabled, we should expect to see more
packet loss from iperf test but the value of packet loss after hacking is
still 0%.

I did a control experiment by disabling ack instead of retry (this one is
confirmed to be no retry), the packet loss will increase from 0% to 10%
with the same setting.

I think there is still some parts going wrong to disable retry completely.
Does anyone have idea?

Marcus


2014-04-17 13:40 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>:

> Hi Marcus,
> Yes, as I suggested before, you should change it in driver code.
> This value in mac80211 codebase is not reflected in ath9k driver(atleast)
> where the default is 10 retransmits.
> And if someone can explain how does minstrel work with default as 7
> retransmits while driver does 10 retransmits,
> that will be awesome!
>
> -
> Abhinav
>
>
>
> On Wed, Apr 16, 2014 at 9:49 PM, marcus muffin <ath9kmuffin@gmail.com>wrote:
>
>> hi all,
>>
>> I found that there is a retry value in net/wireless/core.c
>>
>> 348         rdev->wiphy.retry_short = 7;
>> 349         rdev->wiphy.retry_long = 4;
>>
>> If i set those values to 0. the retry will still exist. Is it correct?
>>
>> Marcus
>>
>>
>> 2014-03-26 21:34 GMT+08:00 abhinav narain <abhinavnarain10@gmail.com>:
>>
>> Hi,
>>> just change value from 10 to 0 for retries to be zero!
>>>
>>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/init.c#L954
>>>
>>> mac80211 API does not update this in ath9k for some reason and the
>>> default
>>> value of retries is 7 in rate minstrel which has also to be changed.
>>>
>>> Thanks,
>>> Abhinav
>>>
>>>
>>> On Wed, Mar 26, 2014 at 5:10 AM, Holger Schurig <holgerschurig@gmail.com
>>> > wrote:
>>>
>>>> 1. "iwconfig" is outdated, don't use it. Use "iw" instead
>>>> 2. As noted in the mail you linked to, the retry is also done by
>>>> software in the mac80211 layer and in the ath9k driver
>>>> 3. ath9k based-cards don't have firmware
>>>>
>>>> So, what you have basically do is to find out where in
>>>> drivers/net/wireless/atheros and net/mac80211 or net/wireless the
>>>> software-retry handling is taking place and make this switchable. LXR
>>>> tells me that IEEE80211_FCTL_RETRY is used in ath9k, see
>>>>
>>>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/xmit.c#L357
>>>> . It seems that the ath9k has a max number of retries defined:
>>>>
>>>> http://lxr.linux.no/linux+v3.13.5/drivers/net/wireless/ath/ath9k/ath9k.h#L653
>>>>
>>>> Hope that puts you into the right direction.
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140419/515978ad/attachment.htm