Wi-Fi speeds measured and improved - Ethernet Parameter can help

RouterOS Wireless Networking
1

Hello Mikrotik Wifi Fans :slight_smile:

Mikrotik is always said to have slower WiFi speeds than other manufacturers - That is often correct.
But a parameter can help - at a point where you wouldn’t expect it - with the Ethernet parameters
Yes, correct Ethernet (not WIFI)
Normally, WLAN is connected to several ethernet ports via a bridge.
For example, one of the LAN ports has a computer with an IPERF server. If you now measure the WIFI speed with this server, you often get relatively low speeds.
Here’s an example: Laptop Lenovo(Wifi 5Ghz) <> Wifi Side> (MT RB4011)> Ether 4<> Raspberry PI 3 Plus Measurement with IPERF3
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 117 MBytes 98.5 Mbits/sec 207 sender
[ 5] 0.00-10.00 sec 117 MBytes 98.2 Mbits/sec receiver
Now set follow parameters(default is always off):
set [ find default-name=ether4 ] rx-flow-control=on tx-flow-control=on
Then measure again - no other parameters have been changed - the laptop has not been moved
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 360 MBytes 302 Mbits/sec 91 sender
[ 5] 0.00-10.00 sec 358 MBytes 300 Mbits/sec receiver

Another measurement against a Fritzbox on Ether1 with Iperf (not Iperf3)
before
[ ID] Interval Transfer Bandwidth
[ 3] 0.0000-10.0132 sec 152 MBytes 128 Mbits/sec

set [ find default-name=ether1 ] rx-flow-control=on tx-flow-control=on

thereafter
[ ID] Interval Transfer Bandwidth
[ 3] 0.0000-10.0222 sec 439 MBytes 368 Mbits/sec
Same thing with ping:
before
64 bytes from 192.168.100.5: icmp_seq=1 ttl=64 time=2.43 ms
64 bytes from 192.168.100.5: icmp_seq=2 ttl=64 time=2.53 ms
64 bytes from 192.168.100.5: icmp_seq=3 ttl=64 time=2.53 ms
64 bytes from 192.168.100.5: icmp_seq=4 ttl=64 time=2.63 ms
64 bytes from 192.168.100.5: icmp_seq=5 ttl=64 time=2.24 ms
thereafter
64 bytes from 192.168.100.5: icmp_seq=20 ttl=64 time=0.847 ms
64 bytes from 192.168.100.5: icmp_seq=21 ttl=64 time=0.894 ms
64 bytes from 192.168.100.5: icmp_seq=22 ttl=64 time=0.893 ms
64 bytes from 192.168.100.5: icmp_seq=23 ttl=64 time=0.949 ms
64 bytes from 192.168.100.5: icmp_seq=24 ttl=64 time=0.879 ms
Don’t forget - there’s still a WIFI line in between

So when looking for the bottleneck, don’t just look at the Wifi parameters only…
BTW - no WifiWave2 driver was used(ROS 7.10) only the good old wifi drivers :smiley:
Greetings

2

I think that, for some reson, your mikrotik device did not negotiate gbit link to raspberry, but instead it locked to 100 mbit before parameter change.

3

I agree. That number is awfully suspiciously close to the real-world limit (100mbps-overhead). Your change may have reset the link negotiation, meaning it was at 100mbps but restarting it happened to link up at 1gbps the second time) or you may have some very strange congestion issue resolved by the flow control (but you would see enormous amounts of continuous traffic from devices other than the two devices you were testing) in the interfaces if that were the case…

4

When this kind of tweaking solves your problems, something is SERIOUSLY broken in your network!
Maybe a bad cable, heavy interference, or bad drivers on either side.
Go and find the actual reason instead of locking ethernet parameters…

5

The Ethernet speed was never 100 Mbit, it was always 1 Gbit
The Ethernet is fine! The Ethernet is a CAT5e cabling.
Measurements Ethernet to Ethernet are around 970 Mbit (iperf / filecopy)- if a real PC is used on both sides, because the Raspi manages a maximum of around 500 Mbit. Setting this parameter increases the WIFI speed to the Raspi.
In contrast, when measuring Ethernet to Ethernet, the parameter does not cause any change.