Latest ath10k performance stats
Ben Greear
greearb at candelatech.com
Tue Jun 24 11:04:58 PDT 2014
Using CT firmware, E5 3.7Ghz hex-core station system, slightly slower AP system,
kernel is hacked 3.14.7+.
AP is NOT configured for software-crypt, but station machine is.
Systems are connected with 3 meter high quality COAX SMA cables + 30dB fixed attenuator,
but this is not a fully isolated environment. Running on channel 149, HT80.
UDP connections are configured with 2MB send + receive socket buffers, 1500 MTU sized packets.
AP is acting as router (and running ath10k, etc).
TCP is configured for 10 streams, default OS send/receive buffer management.
Station machine sends to/from eth1 and station, ie it is both ends
of the connection. UDP transmit is tuned to be just above what system
can handle. If you send at full 1Gbps, total received throughput is
around 20% slower.
The rates reported are 'goodput' for the protocol in question.
WPA2 (station RX uses software encryption, so CPU bound)
UDP Download: 530 Mbps
UDP Upload: 610 Mbps
TCP Download: 459 Mbps
TCP Upload: 570 Mbps
Open Authentication
UDP Download: 830 Mbps **
UDP Upload: 615 Mbps
TCP Download: 660 Mbps (400+ ms latency, one way, by the way)
TCP Upload: 570 Mbps
** We currently ignore checksum errors, part of what it takes to make
rx-software-crypt work. But, on high-speed UDP download (Open Auth) we see a fair
bit of what must be legit checksum errors, and our traffic generator sees
corrupted data streams and restarts itself. So throughput is not even.
Will work on fixing this in our kernel, should be able to pay attention to
csum errors IF packet is not encrypted.
Thanks,
Ben
--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k
mailing list