Latest ath10k performance stats

Ben Greear greearb at
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.


Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list