Big difference between UDP and TCP throughput

AP side setup:

  • RouterBOARD 433GL
  • R52Hn
  • AirMax 16 dBi 120 dgs 2x2 dual-pol sector

Client side setup:

  • RouterBOARD SXT 5-HnD

Config:
Band: 5GHz-only-N
Channel Width: 20/40MHz HT Above
Wireless Protocol: nv2
Data Rates: advanced, default
Hw. Retries: 7
Adaptive Noise Immunity: ap and client mode
Preamble Mode: both
HT Rx Chains: chain0, chain1
HT Tx Chains: chain0, chain1
HT Guard Interval: long
HT AMPDU Priorities: 0

Everything else set to default.

I’m getting around 190 Mbps UDP throughput between AP and client, measured with MikroTik Bandwith Test.

On the other hand, TCP throughput is fairly low - around 35 Mbps avg.

Why is that?
Screen Shot 2012-05-03 at 2.41.02 PM.png

Have you tried it from a computer on each side of the link?

It seems to be said daily, UDP doesn’t stress the board’s CPU as badly as TCP.

A 400Mhz cpu will always stuck btest at around 30-40mbps in tcp mode. Use another way to test speeds.

CPU power in the RB can only move about 40Mbps of tcp. Run something to iPerf and you will better results.

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.

One of those never ending topics.

  1. TCP uses one connection, but in real life you get hundreds
  2. You run the test on the board. The test generates random data that is sent to the other machine. Generating this data takes a lot of resources
  3. Run the test on very powerful machines, so that your link is in between. Never run such tests on the RouterBOARD

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.