Re: [ath9k-devel] ath9k_hw_addrxbuf_edma
Hi, Following are the values for the descriptor and 64 bytes of data Descriptor: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x5c 0x80 0x0a 0x00 0x41 0x6b 0x6d 0x2e 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x03 0x00 0x03 0x00 0x88 64 bytes of data: 0x01 0x2c 0x00 0xe4 0xce 0x8f 0x63 0xf5 0x35 0x00 0x1c 0xb3 0xc3 0x4b 0x31 0xe4 0xce 0x8f 0x63 0xf5 0x35 0xe0 0xad 0x00 0x00 0xe0 0x00 0xaa 0xaa 0x03 0x00 0x00 0x00 0x08 0x00 0x45 0x00 0x00 0x34 0x37 0xa5 0x40 0x00 0x40 0x06 0xec 0x17 0x0a 0x01 0x01 0x03 0x0a 0x02 0x02 0x02 0x4a 0xb7 0xcd 0x87 0xf0 0x01 0x8b 0xf5 Thanks, Astrit On 25 October 2014 19:31, Adrian Chadd adr...@freebsd.org wrote: On 25 October 2014 03:38, Astrit Zhushi a.zhu...@cs.ucl.ac.uk wrote: Hi, Adrian Thanks for the reply. I did print some of the descriptor fields: DescId=0 datalen=92 tstamp=3289088044 DescId=0 datalen=92 tstamp=3289241267 DescId=0 datalen=0 tstamp=0 DescId=0 datalen=92 tstamp=3312687323 (datalen seems to be wrong, I send 1500 bytes long data packets) I will return -EINPROGRESS on the (MS(rxsp-ds_info, AR_DescId) != 0x168c) check and run some experiments and see what results do I get. Hi, can you print out the rest of the descriptor? Even just hexdump the descriptor fields and the first like 64 bytes of the payload (if it exists) - we can parse those here. :-) -adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] 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. 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) 00011 11100011010110100 1 111010100 110010101 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 Abedia2ab...@uwaterloo.ca mailto:a2ab...@uwaterloo.cawrote: 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@lists.ath9k.org mailto:ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Questions regarding ath9k and new EN 300 328 regulation
Hello Zefir, Thanks a lot for your answer. This helps me a lot. If I correctly understand, the ability of ath9k to detect all pulses may also depend of the platform performances. So on an embedded platform with limited performances, we may observe more pulses losses than on a more powerful platform. Is this a right statement? What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it to enable the detection of 0.5usec. pulses? Thanks in advance for your answer. Best regards Adrien On Mon, Oct 27, 2014 at 11:43 AM, Zefir Kurtisi zefir.kurt...@neratec.com wrote: On 10/24/2014 05:23 PM, Adrien Decostre wrote: 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? The pattern detector currently used in ath was initially developed for ath9k when EN 300.328 v1.5.1 was released. It passed the ETSI certification in a German lab and the source code (besides moving it up in the tree to be also available for 10k) was basically not touched ever since. I did not track all the DFS requirement changes up to the latest v1.9.1 draft, but afaik the sole difference relevant for the detector is the reduction of the shortest pulses width in the test pattern specification from 0.7 to 0.5us. With that, the chance of the current implementation to pass a v1.8 certification depends on ath9k's ability to detect the shorter pulses. I did some initial measurements years ago to get a rough picture, which showed that the ath9k is losing like 30% of the 0.5us pulses (as compared to .7us). With the patches you referred, YMMV - you would need to perform thorough statistical analyses to get an estimate on whether it would pass. As for the adaptivity tests, they are not part of DFS (see note in 4.9.1) and maybe would best fit within the ACS module (http://wireless.kernel.org/en/users/Documentation/acs). The current DFS support available in ath9k is limited to bare radar detection, which is enabled through CONFIG_CFG80211_CERTIFICATION_ONUS. Cheers, Zefir ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Questions regarding ath9k and new EN 300 328 regulation
On 10/27/2014 03:18 PM, Adrien Decostre wrote: Hello Zefir, Thanks a lot for your answer. This helps me a lot. If I correctly understand, the ability of ath9k to detect all pulses may also depend of the platform performances. So on an embedded platform with limited performances, we may observe more pulses losses than on a more powerful platform. Is this a right statement? No, there is no bottleneck in the platform performance. Presumed radar pulses are reported as RX_ERROR descriptors and even lower end embedded systems are able to handle the load. What makes the difference with the minimum pulse width is the chip DFS engine's ability to isolate and identify very short spikes as potential radar pulses. This goes very deeply into material I had available under NDA while implementing the DFS support for ath9k. If you intend to work on that topic, I encourage you to contact the folks at QCA and join their 'NDA for Developers' program. The document you want to read is 'Baseband DFS 2 (Radar) Micro-Architecture'. What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it to enable the detection of 0.5usec. pulses? Yes, this driver specific flag (also available for 10k) you need to set to get the DFS detector built (not related to pulse width). It essentially shifts the responsibility of the product working in restricted bands to you / the manufacturer. Thanks in advance for your answer. Best regards Adrien Good Luck, Zefir ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Questions regarding ath9k and new EN 300 328 regulation
Dear Zefir, Thanks a lot for these precisions, This makes thing more clear. There is still one thing unclear to me. If we do not consider working on the DFS channels and that we only want to operate on channels 36, 40, 44 and 48 in EU. Do we still need to enable DFS flags in ath9k to comply with EN 300 328 v1.8.1. I mean, is the same pulse detector algorithm used for DFS and for the adaptivity tests on channels 36 to 48? Many thanks in advance for your answer. Best regards Adrien On Mon, Oct 27, 2014 at 3:50 PM, Zefir Kurtisi zefir.kurt...@neratec.com wrote: On 10/27/2014 03:18 PM, Adrien Decostre wrote: Hello Zefir, Thanks a lot for your answer. This helps me a lot. If I correctly understand, the ability of ath9k to detect all pulses may also depend of the platform performances. So on an embedded platform with limited performances, we may observe more pulses losses than on a more powerful platform. Is this a right statement? No, there is no bottleneck in the platform performance. Presumed radar pulses are reported as RX_ERROR descriptors and even lower end embedded systems are able to handle the load. What makes the difference with the minimum pulse width is the chip DFS engine's ability to isolate and identify very short spikes as potential radar pulses. This goes very deeply into material I had available under NDA while implementing the DFS support for ath9k. If you intend to work on that topic, I encourage you to contact the folks at QCA and join their 'NDA for Developers' program. The document you want to read is 'Baseband DFS 2 (Radar) Micro-Architecture'. What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it to enable the detection of 0.5usec. pulses? Yes, this driver specific flag (also available for 10k) you need to set to get the DFS detector built (not related to pulse width). It essentially shifts the responsibility of the product working in restricted bands to you / the manufacturer. Thanks in advance for your answer. Best regards Adrien Good Luck, Zefir ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_hw_addrxbuf_edma
Hi, Since I don't know what ordering is going on with the descriptor data, can you modify the code to post the descriptor data as uint32_t's? The fact the descriptor data has that incrementing value from 0x32 - 0x39 is .. disconcerting. Maybe the hardware didn't actually write into all of those fields and that's left-overs from your kernel malloc or something? Thanks, -adrian On 27 October 2014 03:41, Astrit Zhushi a.zhu...@cs.ucl.ac.uk wrote: Hi, Following are the values for the descriptor and 64 bytes of data Descriptor: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x5c 0x80 0x0a 0x00 0x41 0x6b 0x6d 0x2e 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x03 0x00 0x03 0x00 0x88 64 bytes of data: 0x01 0x2c 0x00 0xe4 0xce 0x8f 0x63 0xf5 0x35 0x00 0x1c 0xb3 0xc3 0x4b 0x31 0xe4 0xce 0x8f 0x63 0xf5 0x35 0xe0 0xad 0x00 0x00 0xe0 0x00 0xaa 0xaa 0x03 0x00 0x00 0x00 0x08 0x00 0x45 0x00 0x00 0x34 0x37 0xa5 0x40 0x00 0x40 0x06 0xec 0x17 0x0a 0x01 0x01 0x03 0x0a 0x02 0x02 0x02 0x4a 0xb7 0xcd 0x87 0xf0 0x01 0x8b 0xf5 Thanks, Astrit On 25 October 2014 19:31, Adrian Chadd adr...@freebsd.org wrote: On 25 October 2014 03:38, Astrit Zhushi a.zhu...@cs.ucl.ac.uk wrote: Hi, Adrian Thanks for the reply. I did print some of the descriptor fields: DescId=0 datalen=92 tstamp=3289088044 DescId=0 datalen=92 tstamp=3289241267 DescId=0 datalen=0 tstamp=0 DescId=0 datalen=92 tstamp=3312687323 (datalen seems to be wrong, I send 1500 bytes long data packets) I will return -EINPROGRESS on the (MS(rxsp-ds_info, AR_DescId) != 0x168c) check and run some experiments and see what results do I get. Hi, can you print out the rest of the descriptor? Even just hexdump the descriptor fields and the first like 64 bytes of the payload (if it exists) - we can parse those here. :-) -adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
