Graf Monika | 31 Oct 17:33 2014
Picon

Time-of-flight positioning - Atheros

Hello Everyone

I am currently at a project where I am using Atheros Chipsets AR9590 with the ath9k driver on Debian.
I am wondering how the time-of-flight information can be retrieved per packet in most recent Atheros chipsets.
Could you tell me how that I get that out of the driver? Or which register do I have to access in order to get the
hardware timestamp (in nanosec)?

Thank you for your help!

Monika
Dan Carpenter | 29 Oct 16:48 2014
Picon

[patch] ath9k: fix some debugfs output

The right shift operation has higher precedence than the mask so we
left shift by "(i * 3)" and then immediately right shift by "(i * 3)"
then we mask.  It should be left shift, mask, and then right shift.

Signed-off-by: Dan Carpenter <dan.carpenter <at> oracle.com>

diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 2a2a17d..c9afc15 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
 <at>  <at>  -455,7 +455,7  <at>  <at>  static ssize_t read_file_dma(struct file *file, char __user *user_buf,
 			 "%2d          %2x      %1x     %2x           %2x\n",
 			 i, (*qcuBase & (0x7 << qcuOffset)) >> qcuOffset,
 			 (*qcuBase & (0x8 << qcuOffset)) >> (qcuOffset + 3),
-			 val[2] & (0x7 << (i * 3)) >> (i * 3),
+			 (val[2] & (0x7 << (i * 3))) >> (i * 3),
 			 (*dcuBase & (0x1f << dcuOffset)) >> dcuOffset);
 	}
Felix Fietkau | 27 Oct 13:05 2014

Re: strange MPDU loss pattern

Hi Seongho,

that paper looks quite interesting.
Are you planning to publish code/patches for your implementation as well?
It would be nice to have dynamic A-MPDU limiting integrated in minstrel_ht.

Thanks,

- Felix

On 26/10/2014 12:14 AM, Seongho Byeon wrote:
>
> Hi, I am Ph.d. student in Seoul National University , Korea.
> Recently, we have dealt with the problem you observe, and we published
> a paper into CoNEXT 2014 which is a major conference in our field.
>
> Title of the paper 'MoFa: Mobility-aware Frame Aggregation in WiFi
> networks'.
> You can download it a site below.
> http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/14-CONEXT-BYEON.pdf
> <http://www.mwnl.snu.ac.kr/%7Eschoi/publication/Conferences/14-CONEXT-BYEON.pdf>
> If you have a question please contact me anytime.
>
> Best regards,
> Seongho Byeon.
>
> Thank you for sharing the story.
> Even if I consider interference as a possibility, still I can't
> justify the higher
> chance of frame loss in the second half of the aggregate frame.
(Continue reading)

Ali Abedi | 27 Oct 02:50 2014
Picon
Picon

Re: strange MPDU loss pattern

Dear Seongho ,

Thank you for your reply. Very good paper! I know about this conference. I am a Ph.D. student
in computer science too.

I am very certain that what we observe is what you found in this paper. I CC this to the mailing list so that others find out about this problem.  Your observation explains why with the start of a new aggregated frame, error rate decreases again.

Best,
Ali

On 26/10/2014 12:14 AM, Seongho Byeon wrote:

Hi, I am Ph.d. student in Seoul National University , Korea.
Recently, we have dealt with the problem you observe, and we published a paper into CoNEXT 2014 which is a major conference in our field.

Title of the paper 'MoFa: Mobility-aware Frame Aggregation in WiFi networks'.
You can download it a site below.
http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/14-CONEXT-BYEON.pdf
If you have a question please contact me anytime.

Best regards,
Seongho Byeon.

Thank you for sharing the story.
Even if I consider interference as a possibility, still I can't justify the higher
chance of frame loss in the second half of the aggregate frame.

We use

PCI-express 3 antenna dual band cards
product: AR93xx Wireless Network Adapter
and/or
Atheors AR5B97 which is a 2.4 GHz dual antenna internal card in a laptop

we also tried TP-LINK TL-WDN4200 N900as the receiver.

However we see the same results.
we mostly use MCS 20-23, sgi = 0, 20 MHz channels.

The loss pattern is something like this
(each line is an imaginary aggregated frame and each bit is the fate of the MPDU)

11111111111100011000000000000
11111110001101011010000000000
11111000000000000000000000000
11111111111010100000000000000
11111100101010000000000000000

The interesting part is that with the start of the next frame error rate goes down initially
then it goes up again in the second portion of the packet.

Best,
Ali


On 25/10/2014 2:30 PM, Adrian Chadd wrote:

On 25 October 2014 08:28, Ali Abedi<a2abedi <at> uwaterloo.ca>wrote:

Hi Adrian, We have a high end spectrum analyzer. So we are sure there is no background interference We run our experiments in the 5 GHZ spectrum. The channel conditions can still vary due to the movement of the people in the vicinity of the experiment setup. We select a rate that experiences at least 20% error on average. Since if the error is 100% or 0% it's not interesting for us. My point is if the channel conditions change the distribution of failed packets should be uniform. The first and second half of the packets have the same chance to be received successfully.

Here's a little story. My first wifi contract had me spend months trying to figure out why an AP was losing its mind. It'd get stuck in a "stuck beacon" loop and only a hard powercycle of /all/ of the access points in an area would clear it. It turned out that the PCB design had some non-grounded / non-populated tracks that just "happened" to form a 2GHz resonator. Once we grounded those tracks, the APs started behaving themselves. The company in question spent months with high end spectrum analysis kit in the lab (where it never happened) and underground (where it did happen.) It's only after they stuck the spectrum analyser probe _inside the access point_ right up close to the NIC did they see it. Here's the spectrum analyser traces. You can see the peak.http://www.creative.net.au/ath/So, weirder crap has happened. Which NICs and which MCS rates are you using? -adrian

_______________________________________________
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
Astrit Zhushi | 24 Oct 18:12 2014
Picon
Picon

ath9k_hw_addrxbuf_edma

Hi,

I was wondering if someone can help me understand receiver buffer
management on the ath9k driver.

While running TCP experiments using an AP and a wireless node (both
running  AR9380 mini PCI-e cards, with PCI-e adapter) I noticed that
TCP was invoking fast retransmit. At the transmitter, the retry
counters didn't show that the frame was dropped. In addition, looking
at the over the air captured traces (by a third party wireless node),
the receiver's card actually acknowledges the missing frame and the
traces show only one transmission of the missing frame.
Instrumenting the driver I noticed that the missing frames are being
dropped because the received frame descriptor ID didn't match that of
the Athero's vendor ID.
That is, AR_DescId=0 and MS(rxsp->ds_info, AR_DescId) != 0x168c (maybe
replace it with ATHEROS_VENDOR_ID?) condition on ar9003_mac.c fails.

So I started looking at the way the receive buffers are managed by the
ath9k driver. This is my understanding so far:

Before the the card can use the DMA allocated buffers (the pool of 512
buffers kept in rx.rxbuf, they are added to ATH9K_RX_QUEUE_LP (128
buffers) or ATH9K_RX_QUEUE_HP (16 buffers) FIFO queues) and then the
hardware is told about the address by calling ath9k_hw_addrxbuf_edma
function. After which point the hardware can make use of those
buffers.

On a receive interrupt, the driver processes incoming buffers, calls
ath_edma_get_buffers, removes the buffer from rx_edma->rx_fifo
(__skb_unlink(skb, &rx_edma->rx_fifo). This buffer ends up being put
back to the rx.rxbuff pool.
I don't see any call informing the hardware that it shouldn't be using
that buffer. It could be that the equivalent of this is happening
somewhere in the code, but I am missing it?

The only place where the descriptor is memset to zero is when calling
ath_rx_edma_buf_link, before telling the hardware that it can use the
buffer. Now supposing that the card still thinks that it can use a
buffer, and memset(0) is called on the same buffer (because it is
being added back to the rx.rx_buf queue) wouldn't I end up receiving
frames where AR_DescId is 0?

I hope I was clear enough

Thanks,
Astrit
Ali Abedi | 24 Oct 18:04 2014
Picon
Picon

strange MPDU loss pattern

Hello,

We study the effects of 802.11n frame aggregation on throughput. We 
noticed a
strange pattern in the MPDU loss within an aggregated frame. It seems 
that the
second half of the MPDUs (those with higher sequence numbers) in an 
aggregated frame
are more likely to be lost. Is this a known fact or is there any 
explanation for it?

For example if 32 frames are aggregated with sequence numbers 100 to 131.
Frames with sequence numbers 100-115 are more likely to be received 
correctly
than 116-131.

Best,
Ali
Adrien Decostre | 24 Oct 16:58 2014
Picon

Questions regarding ath9k and new EN 300 328 regulation

Dear all,

 

I am looking for information about the compliancy of the ath9k driver to the EN 300 328 ETSI regulation.

Would someone know if ath9k has already been tested for this regulation?

Is it needed to enable any specific flag in ath9k to guarantee compliancy to the adaptivity tests described in EN 300 328?

 

I already tried by applying the patches “ath9k: Fix regulatory compliance” (http://www.spinics.net/lists/linux-wireless/msg115798.html)  and “ath9k: Fix ETSI compliance for AR9462 2.0” (http://www.spinics.net/lists/linux-wireless/msg118665.html) but this does not seem to be sufficient.

 

Many thanks in advance for any help

 

Best regards

 

Adrien

_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Kamran Nishat | 23 Oct 16:32 2014
Picon

Re: Block ACK without frame aggregation

It is a part of 802.11n because of compatibility with 802.11e. But because 802.11n gives a much more advanced AMPDU based thing I think no one implemented it.  It not a mandatory  part of WMM I suppose. 

On Thu, Oct 23, 2014 at 7:22 PM, Kamran Nishat <kamran.nishat <at> gmail.com> wrote:
I was talking about the same one. it was introduced in 802.11e (Tx-OP) not in 802.11n

On Thu, Oct 23, 2014 at 7:19 PM, Ali Abedi <a2abedi <at> uwaterloo.ca> wrote:
Dear Adrian and Kamran,

Thanks for your replies. I think we are not referring to the same concept.
Can you please have a look at the attache diagram. I need the middle one
the immediate BA not delayed BA.


Thanks,
Ali




On 14-10-22 11:18 PM, Adrian Chadd wrote:
I don't think mac80211 supports delayed-BA. :(


-adrian


On 22 October 2014 08:38, Ali Abedi <a2abedi <at> uwaterloo.ca> wrote:
Hello,

I am interested to know if we can send multiple packets (non-aggregated,
single packets) and then ask
for a block ACK? I like to know if this functionality has been
implemented in ath9k or if
it is possible to achieve this with slight code modifications.

What I need:
Frame-SIFS-Frame-SIFS-Frame-SIFS-REQ Block ACK-SIFS-Block ACK

Best,
Ali
_______________________________________________
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
Li, Hongchun | 23 Oct 06:54 2014

Re: FRDC material for meeting in 10.23

Hi, Oleksij,

 

I mistakely send an email to the maillist.

I don’t know who the administrator of the maillist.

Can you help me to delete the email?

Thank you.

 

Best Regards,

Li Hongchun

 

From: Li, Hongchun/ 红春
Sent: Thursday, October 23, 2014 12:45 PM
To: (ath9k-devel <at> lists.ath9k.org)
Subject: FRDC material for meeting in 10.23

 

Hello, Yamashita-san,

 

The attached files are FRDC’s material for meeting today.

Please check and refer.

 

 

Best Regards,

Li Hongchun

 

------------------------------------------------

Li Hongchun

FUJITSU R&D CENTER CO.,LTD.

15/F,Tower A, Ocean international Center,No.56

Dong Si Huan Zhong Rd,Chaoyang District,Beijing P.R.China 100025

TEL(010)59691000 Ext.5654 FAX:(010)59691504

E-mail:  lihongchun <at> cn.fujitsu.com

----------------------------------------------------

 

_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Ali Abedi | 22 Oct 17:38 2014
Picon
Picon

Block ACK without frame aggregation

Hello,

I am interested to know if we can send multiple packets (non-aggregated, 
single packets) and then ask
for a block ACK? I like to know if this functionality has been 
implemented in ath9k or if
it is possible to achieve this with slight code modifications.

What I need:
Frame-SIFS-Frame-SIFS-Frame-SIFS-REQ Block ACK-SIFS-Block ACK

Best,
Ali
이재훈 | 22 Oct 09:09 2014

Questions about ath9k driver

Hi, my name is jaehoon Lee and a graduate student at Seoul National University.

 

Recently, I bought the alix 2d2 device and wireless card(wlm200nx) for experiment the IEEE 802.11aa.

 

How can I install the ath9k driver and open FirmWare for WiFi networks in linux such as Ubuntu?

 

Thanks for reading my questions.

 

Best regards

 

 

Jaehoon Lee

_______________________________________________
ath9k-devel mailing list
ath9k-devel <at> lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Gmane