Hello,
Christian - thanks for the pointer to the function that sets the keys
on the AR9170. I am still figuring out how to use 64 clients with h/w
encryption on the AR9170 - enabling debug/tracing in my build isn't as
straightforward as suggested by the wiki.
However, I did find some very helpful information in the debug files
in 'debugfs' including the number of retries.
The current value is 4 for long packets and 7 for short packets.
I think the small # of retries for regular data packets may be one
reason why I am seeing some throughput problems at longer ranges.
How do I change the number of retries for long packets? Is this a
build-time configuration or can I change it at run-time?
Thanks,
- Harshal
On Sunday, July 31, 2011 06:48:46 PM Harshal Chhaya wrote:
> I am still figuring out how to use 64 clients with h/w
> encryption on the AR9170 - enabling debug/tracing in my build isn't as
> straightforward as suggested by the wiki.
Actually, to do this thing correctly, I recon you should ask your employer
to get you the AR9170 chip documents from atheros qualcomm [if you haven't
acquired them already.]
> However, I did find some very helpful information in the debug files
> in 'debugfs' including the number of retries.
> The current value is 4 for long packets and 7 for short packets.
I don't think that the term "short packets" is what you think it is. :D
> I think the small # of retries for regular data packets may be one
> reason why I am seeing some throughput problems at longer ranges.
Actually, your problem could be related to this thread:
http://www.spinics.net/lists/linux-wireless/msg73850.html
Furthermore, what's "longer range"? Is it 10-20 meters or are
you talking about 200m+? [Note: mac80211 has a switch to select
different coverage classes. The AR9170 MAC has a register
AR9170_MAC_REG_ACK_EXTENSION to up the ACK timeout]
> How do I change the number of retries for long packets? Is this a
> build-time configuration or can I change it at run-time?
Actually, the number of retries is controlled by the selected
mac80211's rate control algorithm. However, you first take a
look at debug/ieee80211/phy0/statistics/failed_count and see
if it really is the lack of additional "retries" which causes
data loss.
Regards,
Chr
On 1 August 2011 10:29, Harshal Chhaya <[email protected]> wrote:
>>> However, I did find some very helpful information in the debug files
>>> in 'debugfs' including the number of retries.
>>> The current value is 4 for long packets and 7 for short packets.
>> I don't think that the term "short packets" is what you think it is. :D
>
> From what I understand, short packets are smaller than the
> RTSThreshold and long packets are larger than that value. Since my
> RTSThreshold is undefined, I imagine all my data packets are 'long
> packets'.
If it's even peripherally related to the Atheros MAC terminology, then
that's the number of RTS retries and then entire packet retries.
Ie:
* short would be "how many times to try sending an RTS, expecting to
hear an CTS in response but not hearing it."
* long would be "how many times to try sending the whole packet,
expecting an ACK in response, but not hearing it."
Adrian
On Sun, Jul 31, 2011 at 2:12 PM, Christian Lamparter
<[email protected]> wrote:
> On Sunday, July 31, 2011 06:48:46 PM Harshal Chhaya wrote:
>> I am still figuring out how to use 64 clients with h/w
>> encryption on the AR9170 - enabling debug/tracing in my build isn't as
>> straightforward as suggested by the wiki.
> Actually, to do this thing correctly, I recon you should ask your employer
> to get you the AR9170 chip documents from atheros qualcomm [if you haven't
> acquired them already.]
Christian,
I have the data sheet for this chip which tells me that the chip has
support for 64 pairs of keys. But what I can't figure out is why I can
use only 32 of them when I use hw crypto. All my clients use CCMP and
I would like to use the hw crypto if possible.
I was hoping to get some debug/trace information from carl9170 but
every time I try to enable tracing, my build config gets messed up and
my build fails. I am also hoping that this tracing helps me track down
why the wireless connection in unstable when I enable power save on
the clients.
>> However, I did find some very helpful information in the debug files
>> in 'debugfs' including the number of retries.
>> The current value is 4 for long packets and 7 for short packets.
> I don't think that the term "short packets" is what you think it is. :D
>From what I understand, short packets are smaller than the
RTSThreshold and long packets are larger than that value. Since my
RTSThreshold is undefined, I imagine all my data packets are 'long
packets'.
>> I think the small # of retries for regular data packets may be one
>> reason why I am seeing some throughput problems at longer ranges.
> Actually, your problem could be related to this thread:
> http://www.spinics.net/lists/linux-wireless/msg73850.html
It could be related to that discussion - but I am seeing the problem
with regular data packets after the authentication handshake. I think
the short # of retries coupled with minstrel_ht's rate management is
causing a higher failure count than if I had more retries. I can
possibly try a different rate control algo but I figured changing the
retry count is probably easier and better for cases where the range is
in the 5-10 m range.
> Furthermore, what's "longer range"? Is it 10-20 meters or are
> you talking about 200m+? [Note: mac80211 has a switch to select
> different coverage classes. The AR9170 MAC has a register
> AR9170_MAC_REG_ACK_EXTENSION to up the ACK timeout]
I am talking ~20-30 m (~65-100 ft). I don't think I need to change the
ACK timeout for this range.
>> How do I change the number of retries for long packets? Is this a
>> build-time configuration or can I change it at run-time?
> Actually, the number of retries is controlled by the selected
> mac80211's rate control algorithm. However, you first take a
> look at debug/ieee80211/phy0/statistics/failed_count and see
> if it really is the lack of additional "retries" which causes
> data loss.
I didn't know that the number of retries is controlled by the rate
control logic - that's very useful information. I had assumed that the
number is fixed. I will look at the 'failed_count' number for the
stations at the target range and see if it tells me the reason for the
failure.
Thanks,
- Harshal