wireless low speed by www.speedtest.net

I have a Router 751U-2HnD problem with Routerboard.:
Wifi network when I get to test the speed at http://www.speedtest.net 50% less to come off as it should. Which is a problem. Whether this is due to a problem with the router itself that too much or really ruuteris my area 2.4 Ghz frequency

Help!
Thank you very much all!






This is a test by 50% less but really default cable speed is (50/10)

“I have a problem with my new car. My wife told me it is doing only 50% of the speed than what the brochure told me it could do… please help me…”

Your info in your post has not enough information for anyone to give you even a direction towards the solution of your possible problem.

Hi

We have experienced the same on our links. We have a 50Mbps leased line at the base station and by the time it comes out the tower to a clients site its 20-30Mbps. When the speed test via speedtest.net is done on the wire at the base we get the full 50Mbps? Even more confusing, when we run the btest tool the internal speed we get is 175-200mbps (CPE to core router at the base) over the air. We are using 2x RB600A boards with R52nM cards. link is less than 1Km and signal at each end is around -60. NV2 is in use without security to see if that was the issue but it wasn’t. Base is in AP/Bridge mode and the client is on Station Bridge mode. All boards are using ROS 5.14 (I think). One idea we had was the cards do not react fast enough to the requirement for bandwidth (idle links usually sit at the lowest speed possible until in use). Btest ramps up the speed slowly over 10-20 seconds but speedtest.net sends out a short but high speed burst of traffic.

We also noticed speedtest.net shows a lower speed than doing a ptp test using mikrotiks btest tool. We have a 250Mbps leased line on another site and that gets a max speed of around 150-160Mbps on speedtest.net but btest to our rack in a seperate dc will max out at the full 250mbps.

It’s not urgent we fix ours (it’s under used currently) just curious why it does this?

Jon Dixon

Btest tool can be set to generate tcp or udp traffic, and I’m pretty sure it’s udp on those high numbers you get. However speedtest.net is using tcp as are all ordinary file transfers via http. I’m also getting quite low tcp values even from btest (cpu load not an issue) when udp counts hundreds. Try using nstreme with best fit 3200 and check if it helps a bit for speedtest.net. It did for me..

As for this issue, I would really like someone to enlighten me about how to understand these btest values. It’s good to have a convenient tool, but it’d be nice if it showed the same tcp speed that browser shows while I’m downloading a file or doing a web speedtest. Because at the end of the day, it’s all that matters to customers when they’re poking the screen and telling that I do not give them what is claimed.

Pitty that this is probably not the best place for this topic, but oh well..

TCP speed is influenced by end to end latency. Higher speeds and higher latency needs higher tcp window size to avoid waiting for acks.
Packet loss or delays increase this.
So if you test 2 chained 100mbit links you get other values than testing one 100mbit link.
You have to keep latency low to get high speedtests.

Well this starts to get somewhere. Since most of the traffic ordinary user uses is tcp, this becomes a slight problem. No wonder you do get better results via 100mb ethernet cable than on a full scale 2x2 mimo wifi link. This sort of explains why in some cases nstreme performs better than nv2. I mostly get more udp bandwidth with nv2 and better latency and stability with nstreme. It’s odd, but as long as it works I’m fine with it.

Since udp traffic doesn’t need acks, it sorta explains why this is happening. Are there some medicine to improve tcp performance by adjusting some 11n settings, like ampdu priorities or something like that? And what about nv2 vs nstreme?

Either way, I’d like to hear some more about this issue.

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.