improved wireless driver, faster performance, "wireless fast path" mode

you can test the Fast Path (FP) like this "/queue interface> set wlan1 queue=only-hardware-queue"

but even with FP off, the wireless speed will be improved compared to regular package

channel list and power limit should be working now with the new wireless package.

channel list and power limit should be working now with the new wireless package.

Tried it now but the tx-power was to high (max card rate) for the band. band=5GHz A/N country=Germany.

I took this wireless package on a short test, and as for me it works worse than 5.14 with unspecifed/nstreme.
link:

rb711GA ---10km perfect LOS-- rb411-DBii-FN50pro , mcs12

and with nsteme 5.14 i get speed up to 120mbps with stable ping as old good nstreme,
with 6.12 with new wireles package it begins to choke around 105mbps.
tried to set hardwareonlyqueue, it doesn't make any diff.

btw. as for AR9220 chipset wider (25+25 Mhz) channels are not supported anymore in 6.12 ? ?

Hello uldis. New wireless package will be integrated in next versions (6.14) in standart wireless package?
Or will be still separate?

custom channel width on RB911uag2phnd, with new wireless package is also unsupported.
Will custom channel width option no longer be supported ?

Yes of course, I have superchannel feature enabled.

Confirmed with OmniTIKs.

I have the superchannel license, and I can't enable the custom 30 MHz channel width with wireless-fp enabled. Disabling wireless-fp and enabling wireless it works perfectly.

Today I had a strange problem: switching from nv2 to nstreme makes an RB411AH hardly accessible.
The device cycled Ethernetlink and was accessible for 3-20 seconds on ethernet and then not for
some time. I hardly managed to log in and disable wlan1 to make it accessible again and switch away from
nstreme.
Reboot did not help. I guess nstreme killed the cpu and this in some way kills ethernet connectivity???

How did you test the TCP and UDP speeds?

You see the degradation is not as worse with only the second link.

So my conclusion is that there are hickups/queuing problems which sum up to make a bad
tcp result while udp is not disturbed.

for testing tcp thruput with Mtik Btest, first run btest to 127.0.0.1 to see how much can the board handle.
and as for my tests:

rb433 - cpu 300mhz - TCP test ~40mbps HD, 30/30 FD
rb omnitik cpu 400mhz - TCP ~50mbps HD, 40/40 FD.

so testing tcp with these boards is pointless as they can't do more than above given stats.

for btest a x86 is most effiecient. intel atom 1,6ghz hits 500mbps TCP HD, 375/375 mbps FD.

another matter is fact that on Ros 5.x these results were half worse. so tcp btest on omnitik with 5.x gives even worse results.
and its nothing to do with wireless capacity.

Using 127.0.0.1 you hit the CPU twice as hard as it is sender and receiver.
My tests are reproducable with a speedtest from PC to speedtest.net.
There is a problem other than the speedtest itself.

NAME                    CPU        USAGE
wireless                all          37%
www                     all           0%
ethernet                all        13.5%
queue-mgmt              all           0%
dns                     all           0%
networking              all          12%
mpls                    all         7.5%
management              all           0%
routing                 all         0.5%
idle                    all        21.5%
profiling               all         0.5%
queuing                 all           0%
bridging                all           3%
unclassified            all         4.5%

Using 127.0.0.1 you hit the CPU twice as hard as it is sender and receiver.
My tests are reproducable with a speedtest from PC to speedtest.net.
There is a problem other than the speedtest itself.

Measuring usable bandwidth, especially depending on where you do it, is much trickier than it seems.

I have just made a controlled test. This is it:

FreeBSD - Internet - Cablemodem - OmniTIK ~~~ OmniTIK - FreeBSD

Both FreeBSD systems running iperf3.

iperf3 parameters: 48 connections, TCP, 1 MB window size.

The cablemodem and the cablemodem provider is the unknown here, but, anyway, I have no problem to reach 80 - 100 Mbps of TCP. Even though the cablemodem is crap and I don't think it will be very good at keeping the NAT at 100 Mbps.

Code: Select all

NAME                    CPU        USAGE
wireless                all          37%
www                     all           0%
ethernet                all        13.5%
queue-mgmt              all           0%
dns                     all           0%
networking              all          12%
mpls                    all         7.5%
management              all           0%
routing                 all         0.5%
idle                    all        21.5%
profiling               all         0.5%
queuing                 all           0%
bridging                all           3%
unclassified            all         4.5%

Unless you are doing specific TCP processing at the routers, or there is packet loss, there is absolutely no reason to get different results for TCP and UDP. If you are not doing any special TCP processing, both are IP packets.

The reason for those differences is the higher cost of the TCP bandwidth test running on the Mikrotik hardware. And note that depending on your round trip time (this link has an end to end delay of around 30 ms) you need really large window sizes. I am using 1 MB.

Of course you're right if you want to test the capacity of the link(chain). With a lot of users you'll see this capacity but a single user never see this bandwidth even if the link(chain) is unused.

• ht-rxchains and ht-txchains have been replaced by rx-chains and tx-chains
• channel-width doesn't accept 20/40mhz-ht-above/below any more - channel widths are in new format 20/40mhz-eC/Ce (I guess in preparation for 802.11ac channel widths like 20/40/80mhz-eCee)

I would like to test it also on ptmp on one or two APs and some users.

What happens if APs runs wireless-fp package and users don't?

One other 'gothcha!' I found;

If you made yourself a script to set units to a default setting, the wireless is indeed changed. So the wireless part of the script is full with errors and therefore not accepted. The wireless interface does not even get enabled. So if your routine was to load the scipt (with old format, but now the new wireless package installed) and you think the antenna is ready for deployment in the field.... you're wrong!
You have indeed to make a new script, like 'dohmniq' already sort of pointed at...

UDP & TCP difference:-

In Netmetal(v6.29.1) bandwidth test using udp can get (450Mbps FD)(210Mbps HD), and TCP can get (220Mbps FD)(100MbpsHD).

Anyone can telling me, why udp & tcp bandwidth difference is big?

How do you test the bandwidth?
Beware that the builtin BW test is very CPU intensive.
In case you tested this with BW test feature of your NetMetals, you very likely maxed out the CPU.

For real life results, better use two comuters (one at each peer) and use iperf, you should see much better results.
-Chris

UDP & TCP difference:-

In Netmetal(v6.29.1) bandwidth test using udp can get (450Mbps FD)(210Mbps HD), and TCP can get (220Mbps FD)(100MbpsHD).

Anyone can telling me, why udp & tcp bandwidth difference is big?

In short; because udp is like you send a letter to recipient but you'll never know if it really arrives in proper state. tcp is like guaranteed delivery. If not the mail office will send the package again and again until considered useless to send. It needs to send some extra data with the original package to make sure the sender will know the receiver received the package and that it is received in proper condition. If not the receiver asks sender to send again.
So if your link is not 100% quality you will always have some packages resend and down goes your maximum throughput.

rule of thumb on good links is that you get 50-60% tcp traffic compared to the connection rate. That's a good working link!

This is a normal working nv2 link. Doing the same over a licensed wireless link there is nearly no difference between tcp and udp speed.
The guaranteed delivery causes ack packets to flow in the opposite direction making <5% additional traffic in the opposite direction. Modern OSes (ROS since newer 6.x versions) do much bigger sliding window so there is lower ack-traffic and no need to wait for ack which would slow down the connections.

I am sure MT could do some nv2 optimizations to bring tcp speed to udp - 5-10% if they only invest the time.