Re: ATH10 firmware question

[Ben Greear <greearb@candelatech.com>]

On 11/24/2015 08:19 PM, Michal Kazior wrote:
> On 24 November 2015 at 22:29, Ben Greear <greearb@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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com