On 17 September 2016 at 00:37, Hsu, Ryan wrote:
[...]
>> + /* WMI and HTT may use separate HIF pipes and are not guaranteed to be
>> + * serialized properly implicitly.
>> + *
>> + * Moreover (most) WMI commands have no explicit acknowledges. It is
>> + * possible to infer
On Montag, 19. September 2016 08:43:56 CEST Simon Wunderlich wrote:
[...]
> > We're testing encrypted AP + Mesh quite successfully right now with
> > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
>
On 19 September 2016 at 01:27, Xuebing Wang wrote:
> Hi Community,
>
> ath10k wiki says packet injection isn't supported yet. Is it difficult to
> add packet injection for chip like QCA6174 hw 2.1 in Killer 1525? Thanks.
This would require some tricks:
- monitor vdev can't tx so you'll need othe
Out of curiosity, does ath9k perform at the required rates in a similar
setup?
Sending tcp, udp, or some other protocol? How are you generating the
traffic?
Thanks,
Ben
On 09/18/2016 09:26 PM, Sridhar Kondabathini wrote:
Hi,
When we are testing 802.11 a/g mode throughput measurements on
... and what's "TEC specification" ?
-
a
On 19 September 2016 at 09:28, Ben Greear wrote:
> Out of curiosity, does ath9k perform at the required rates in a similar
> setup?
>
> Sending tcp, udp, or some other protocol? How are you generating the
> traffic?
>
> Thanks,
> Ben
>
>
> On 09/18/2016
It got broken by 0b8e3c4ca29fe2c0efd3d41a76e34a657b9f17a4
Signed-off-by: Nikolay Martynov
---
drivers/net/wireless/ath/ath10k/debug.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/
Hi,
I didnt try with ath9k drivers on the same setup.
we are using WiFi capacity test tool on Lanforge to test the performance,
this will
generate the traffic. we are selecting the UDP protocol (packet - 1472 Bytes).
As per TEC spec. required data rates are given below.
Mode
LANforge is going to be running a modified driver and firmware, though likely
it is no worse at performance in this case than stock code.
What is the device under test?
And, are you in an isolation chamber, using SMA cables, attenuation, etc?
There are lots of things that can impact wifi throug
