Warning message in bridge mode

Ben Greear greearb at candelatech.com
Thu Jun 26 07:34:32 PDT 2014

On 06/26/2014 07:17 AM, Vu Hai NGUYEN wrote:
> Hi Ben,
> Can you create a firmware that is the same as 10.1.467-2-1 but include your fix for promiscuous mode?
> I would like to do the test of rate in bridge network to see if the performance is better or not.
> But as your firmware contain other commit that might make the rate slower so I would like to ask you could create
> this version of firmware.

It would not be easy for me to do that.  While you found a single patch that
fixed the crash for you, I believe it is also dependent on many patches that
came before that one as well.

For your throughput tests, are you using UDP or TCP?  You might try TCP in
case you are hitting the same packet-reordering issue reported in another
email thread.

At least for standard operation (ie, no software-crypt), I doubt my
changes to the firmware had any significant impact on performance
or throughput.


> Thanks in advance,
> Acita-Sodielec
> Route de Mayres - B.P. 9
> ________________________________________
> De : Ben Greear [greearb at candelatech.com]
> Date d'envoi : mardi 24 juin 2014 17:10
> À : Vu Hai NGUYEN; Bruno Antunes
> Cc : Patrick CARNEIRO RODRIGUEZ; ath10k at lists.infradead.org
> Objet : Re: RE : Warning message in bridge mode
> On 06/24/2014 12:39 AM, Vu Hai NGUYEN wrote:
>> I was wrong, the only warning msg is "br0: received packet on wlan0.sta1 with own address as source address".
>> And I have another question: When doing test with iperf, I always have rate from AP to STA higher than STA to AP
>> (380Mbps vs 240 Mbps).This is normal too right? Cause before you told me that when you did the test with your
>> own trafficgenerator, you can get 500+Mbps download, and about 400Mbps upload.
> We have done some tests recently on E5 3.7Ghz systems (ie, top-end-ish server systems)
> that can push 800+Mbps UDP, but can't recall if that is upload or download.
> We need to re-run tests and publish the info.
> Looks like host CPU is very important to higher-speeds with ath10k.  I did a perf top
> months ago, and there was bad contention on a spinlock or two in ath10k driver, so that
> is probably much of the performance problems we see.
> Thanks,
> Ben
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com

Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

More information about the ath10k mailing list