From: "voncken" <cedric.voncken@acksys.fr>
To: "'Ben Greear'" <greearb@candelatech.com>,
"'Michal Kazior'" <michal.kazior@tieto.com>
Cc: <ath10k@lists.infradead.org>,
"'linux-wireless'" <linux-wireless@vger.kernel.org>
Subject: RE: ATH10 firmware question
Date: Wed, 25 Nov 2015 11:41:05 +0100 [thread overview]
Message-ID: <04a201d1276d$c9a6b7c0$5cf42740$@acksys.fr> (raw)
In-Reply-To: <5655530B.9030407@candelatech.com>
Hi,
Thanks for your answer.
> >>>
> >>> 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.
>
In my case I'm testing with mips 64 dual core at 1.2 GHz. The CPU load is around 50% during my test. I'm agree with Ben, the issue is not in CPU.
I tried this morning with different firmware version. I only change the ath10K firmware in client side and I only test the client Tx performance.
Test with firmware 999.999.0.636
Unfortunately this firmware does not support the WDS mode, I need to update my setting. With this firmware I have a better performance, I can reach 700 Mbps.
Test with firmware 10.1.467-ct-15 from candelatech (full community version)
I tested in WDS setting and the same setting of previous firmware to be sure the setting have no impact on the performance. In both case I can reach around 650 Mbps.
I tested with beta-16 firmware from candelatech, but I have a similar performance.
Thanks
Cedric.
prev parent reply other threads:[~2015-11-25 10:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 18:07 ATH10 firmware question Cedric VONCKEN
2015-11-24 21:29 ` Ben Greear
2015-11-25 4:19 ` Michal Kazior
2015-11-25 6:19 ` Ben Greear
2015-11-25 10:41 ` voncken [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='04a201d1276d$c9a6b7c0$5cf42740$@acksys.fr' \
--to=cedric.voncken@acksys.fr \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).