I think it's even more complex than UDP/TCP issues. UDP will give false results because it cares not about packet loss. Simplicticly, when you test with UDP and the packet is corrupted, UDP just carries on regardless and moves onto the next packet, TCP requests a re-send. For this reason, TCP will nearly always give less throughput than UDP over wireless.
The other issue is the number of TCP connections, HTTP is a single connection, and therefore speedtest.net will report a speed similar to that reported by BTEST.EXE using 1 TCP connection. If you increase the TCP connections to the default of 20, then throughput shoots up accordingly. This means that in theory, using http based speedtest sites, 20 users will concurrently see a maximum of 1/20th of that 20 connection speed, or the single connection speed, whichever is the lowest.
What has baffled me however is the following scenario:-
Using a single TCP connection from Radio A to Radio B, we can achieve 60Mb/s in either direction, so far so good. When we test from PC to PC however, both PCs being connected to their radios by 100Mb/s Ethernet we only see 20Mb/s. PC to PC via a switch instead of the radio shows 84Mb/s so it's not PC capability. The Routerboards at each end are 433AHs at 800MHz with R52Hn boards and during the PC to PC test, CPU usage is just 35% so it's not that capability. If we increase connections to 20 then the PC to PC test goes up to 55Mb/s and the radio to radio remains at around 60Mb/s. As far as I can work out therefore, the issue must lie within the RouterOS bridging of the radio and ethernet ports or possibly something to do with different L2 MTUs of ethernet and wireless.
If anyone can explain the above, and offer a solution, it would be most appreciated.