I was getting similar results even with high end equipment like core cloud and power routers… what we found is that the problem was in the wireless legs. I am not sure if I am correct on this, but I think that the UDP packet does not need to transmit back while the TCP does…
We were getting UDP throughput almost x10 the TCP but when we addressed TX issues, the problem was solved. I think, again, I am not a network expert, but I think it had to do with the fact that the TCP packets needed the TX from the client side to be as snappy as the RX to maintain high throughput.
We still get better results with UDP but it’s like 90mbit UDP vs 80mbit TCP.
Thank you. Actually we test from end users browsers, routers, CPEs, demarcation MT board, single connection multiple connections, you name it, TCP always gets lower throughput (even on a cloud core connected directly to a gig fiber circuit or a Mac behind it with Iperf.)
What is interesting that if we connect the same Mac to the fiber handoff we get same results for UDP and TCP, but going behind a Mikrotik no matter how strong with zero configuration other than IP, the TCP performance is at least 30% lower or even worse.
One thing I have not tried is to uncheck connection tracking and play with the TCP MSS which a friend of mine suggested, so I’ll do that. But again:
gig fiber hand off — Cloud Core — Mac (TCP poor performance)
gig fiber hand off — Mac (TCP performance equal to UDP)
By the way normis, at every client now we have a RB, usually 750UP behind the wireless CPE and in-front of their router. We noticed that the speed test results the customers get at speedtest.net and speakeasy, are inline with the same speed tests we get with the RBs when TCP is checked. So while the RB test may not be super accurate, it is very similar results to what our customers see in their browsers, which gives us a great way to troubleshoot. When we get good results from the RB the customer usually gets good results too.