I have to say I'm so very weary of explaining to people, like managers, that the "bitrate" on the label for a wireless product is NOT the bit rate one will achieve when downloading a file, etc... over a wireless link.
Obviously, there is MAC overhead, TCP overhead, etc... that all factor in to dramatically reduce such a rate to a "real world" value.
Here's my dilemma: I've measured a few bridge/WDS type of products for a backhaul application. For example, a layer 2 bridge (WDS) based on a pair of 2x2 devices appears to sustain about 330 Mbps of end-to-end TCP throughput as measured with iperf3, on an apparently inteference-free channel, located just a few meters apart and registering about -30 dBm RSSI. In other words,a rock solid link.
The "Over Air Bit Rate" (OABR) for such a 2x2 operating at MCS9 should be 867 Mbps. 330 Mbps/867 Mbps ~= 38%.
I have seen several references that suggest one can achieve 40%-60% of the OABR in TCP end-to-end testing. My results are on the low end of this, and my expectations are set accordingly.
Surely somewhere there a spreadsheet or other way to explain how the overhead stacks up? Any thoughts? I seriously do not want to have to reverse engineer the whole 802.11ac MAC timing to account for every inefficiency- I'd probably do it wrong if I did. In fact it may be impossible as the layer 2 bridge implementation might be impossible to determine its overhead.
Any thoughts? While I believe the "rule of thumb" mentioned previously is likely accurate, I need a theoretical upper limit that can be used to benchmark products for this backhaul bridge implementation.