@ Marek Thanks for your response.I am aware of the bugus 6 mbits display I was referring the results of batctl tp Should I be using iperf? @Sven Thanks for the explanation. I am going to ask a friend to make a build with those patches for me. The CPU I have been using is a QCA9557 I also have a Gateworks GW5310 so I can do some comparisons and report back my results. Should I be using iperf or is there something else you would recommend for more accurate throughput values.
Daniel
On Mon, Jan 1, 2018 at 4:13 AM, Sven Eckelmann sven@narfation.org wrote:
On Montag, 1. Januar 2018 13:12:53 CET Marek Lindner wrote: [...]
This is a known bug caused by the QCA WiFi driver firmware blob. The exported TX bitrate value is utterly bogus. Only QCA is in the position to fix that.
There have been attempts such as this one: https://github.com/torvalds/linux/commit/c1dd8016ae02557e4f3fcf7339865924d93... Not sure this fix addresses your case. Sven might know.
This only works for 10.4 firmware versions with peer stats enabled. The 10.2.4 firmware versions (only some are actually supported) require following patchset:
- https://patchwork.kernel.org/patch/10092915/
- https://patchwork.kernel.org/patch/10092917/
- https://patchwork.kernel.org/patch/10092919/
And you need the patch mentioned by Marek (+ the patch referenced in it) to get any TX rate values at all.
But QCA already knows that they (relatively often) still report completely bogus values (and only QCA can fix it). And you must understand that the values which you will get here are *a lot* higher than what you can realistically achieve via this link since the TX/RX data rates are actually physical data rates and not the throughput measured via TCP/UDP/... - or by looking at the payload of the actually transported (QoS) data packets.
So let as assume for now that you will lose 50% of the physical data rate to some expected overhead. Then you might still have the problem that each packet has to be retransmitted 4 times (or more) before it can be received by the other end and the aggregation is 1. The TX/RX data rate information in iw will not capture anything of that.
But there can also be a lot of other factors which influence the performance - maybe you CPU is not capable of handling the packet generation and transmission, the MTU is not configured properly on the slave device, the NIC might not be able to transmit a single flow to saturate the link, batman-adv's throughput meter might not handle some packet loss as well as expected, the qdisc (flow dissector) might fail to handle the batman-adv tp packets properly, ...
Kind regards, Sven