ATH10 firmware question
Ben Greear
greearb at candelatech.com
Tue Nov 24 22:19:55 PST 2015
On 11/24/2015 08:19 PM, Michal Kazior wrote:
> On 24 November 2015 at 22:29, Ben Greear <greearb at candelatech.com> wrote:
>> On 11/24/2015 10:07 AM, Cedric VONCKEN wrote:
>>>
>>> Hi,
>>>
>>> I have a simple test platform.
>>> One PC connected to an equipment. This equipment is set in AP
>>> mode.
>>> Another PC connected to another equipment. This equipment is set
>>> in STA + WDS mode.
>>>
>>> Both equipment use the same openwrt Firmware (compat
>>> 2015-07-21), I only changed the ath10k firmware (in
>>> /lib/firmware/ath10k/...).
>>> Both equipment has the same hardware.
>>> I used a clear channel, and VHT80.
>>> The radio was connected with a coaxial cable and I placed 40 dBm
>>> attenuation per Rf chain.
>>> I used the WLN350NX radio card from compex.
>>>
>>> First test : ATH10K firmware 10.2.4.70-2 on both equipment
>>> An iperf from PC connected to the AP to the PC connected
>>> to the STA give 919 Mbps.
>>> An iperf from PC connected to the STA to the PC
>>> connected to the AP give 500 Mbps.
>>>
>>> Second test : ATHK firmware 10.2.4.70.10-2 on both equipment
>>> An iperf from PC connected to the AP to the PC connected
>>> to the STA give 921 Mbps.
>>> An iperf from PC connected to the STA to the PC
>>> connected to the AP give 441 Mbps.
>>>
>>> If I cross the computer I have the same result. I did several
>>> time these test and I always have the same result.
>>
>>
>> We see similar. One thing we notice is that if you actually try to send
>> less
>> throughput, then you get better overall throughput.
>>
>> In other words, trying to send 1Gbps UDP frames will give you more poor
>> throughput than trying to send 650Mbps (in the upload direction).
>>
>> I thought it might be a poor interaction regarding backoff in the
>> ath10k driver/firmware (see the congestion bins in firmware for why
>> this is the case), but even fixing that in firmware didn't improve
>> the situation in my testing.
>
> If CPU is the bottleneck on DUT than overcommiting the UDP traffic at
> the source may lead the ethernet driver to waste CPU cycles on the
> DUT.
You are correct about the overcommit in general, but our systems are quite
overpowered.
We are testing with 3.5Ghz E5 quad-core systems...it is not just a CPU usage
issue. And, exact same hardware runs great (close to 900Mbps) in AP download mode.
Thanks,
Ben
--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k
mailing list