MikroTik released a new wireless driver package lately:
Regarding the RAM requirement, I have to note that my cAP ac device shows over 80 MB of free RAM, even when 30+ clients are concurrently connected. So I assume that there is plenty of RAM left for using the new wireless firmware and drivers on IPQ4018/IPQ4019 devices which have 128 MB of RAM installed.
Also, as this new package contains several firmware files, libraries and linux kernel modules for different chipsets the file npk package is quite big. With its 10MB it is not possible to install it on current devices with 16MB of ROM, e.g. cAP ac, hAP ac2, new wAP ac, …
Of course, I want to have new features like 802.11w and MU-MIMO, WPA3 and better performance on my current MikroTik cAP ac devices. According to https://help.mikrotik.com/docs/display/ROS/WifiWave2 “400Mb/s maximum data rate in the 2.4GHz band for IPQ4019 interfaces” is possible.
While looking around for information about modifying MikroTik´s npk packages, you could find different outdated tools for RouterOS v6 (e.g. https://github.com/kost/mikrotik-npk/). Therefore I want to ask whether someone of you already tried modifying a RouterOS V7 package at all?
Of course, if MikroTik will provide a separate kind of “wifiwave2-lite” package for IPQ/4018/IPQ4019 devices with 16MB of ROM, I wouldn´t have to start this thread at all.
Wave2 requires FAR more resources … ACTIVE Memory Resources [RAM in simple terms] … Wave 2 cannot be supported on MEMORY deprived devices PERIOD. If you are hoping and praying that its possible you are dreaming in vivid color.
You can’t modify packages, they are digitally signed and will not install if you change them in any way.
But I agree it’s clearly possible to make much smaller new wifi package. Also the RAM requirement can be lowered by using smaller buffers. The default sizes are optimized to get absolute maximum performance from wave2 hardware, but even if you scale them down a lot (say 10x smaller) you will have all the advantages of wave2 with possibly slower performance at maximum MCSs, often requiring quite unrealistic signal levels anyway.
It might even be possible to fit it all into 16MB flash if it’s really optimized (remove all debugging info, messages etc.), remove old wifi package completely, build driver with compiler set to optimize for code size instead of performance (again it would be better to have fully working wave2 features with slightly lower performance on some devices than no wave2 at all).
Maybe in general building all non-performance ROS components (winbox, console,…) as code size optimized instead of performance may be a good idea to get a bit more space. If winbox is few milliseconds slower there and there, it will probably not even be noticeable…
I guess you analyzed all ROS parts to claim that none of code is size-optimized?
While I’m looking forward to wave2 driver for hAP ac2 I really hate seeing so many posts telling MT devs what to do, pressing them to rush things (and at the same time nagging over unsquashed bugs). Did occur to anybody that debuging symbols in ROS parts might be necessary to create supouts? I don’t know that either, but I guess it’s possible. I guess many would trade supouts for additional functionality, but then even more bugs would be lurking around.
I’m pretty sure MT will do everything to make their hardware perform as good as it’s possible … and I guess they know their hardware slightly better than most of us, forum members. So let’s give them a break so that they can get ROSv7 out of beta. We’ll try to persuade them to release wave2 drivers for lower end wireless devices then …
I’m just trying to brainstorm some ways to get it running. Yes, I have analyzed the package quite a lot, so while I can’t be sure about used compiler options, I can see some details that may not be normally visible, like that debug info. And I agree with you, removing any debug information will make error reporting and debugging much harder, so it’s not something you would do at this stage of the development… but once it’s stable it’s one of the ways to slim it down. It’s like that scene from Apollo 13 where they have to turn off pretty much each and every non-essential device to stay within energy budget. Slimming software this much is quite ugly process and a lot of stuff has to go. I’m not holding my breath this will actually happen, just saying there are still some ways left to explore and that there is still some hope this might be possible…
Mikrotik has put their implementation for it into DEVELOPMENT branch now.
Meanwhile… Evey other vendor is focused on WiFi 6. Many have had it out for months.
I gave up on Mikrotik wireless for anything critical a long time ago. Mostly for how it doesn’t deal well with interference. Caps-man on a good radio would be a game changer… Notice I typed “good radio”.
But the push back I am going to face with UniF–k having 2 WiFi 6 radio choices, just isn’t worth my time. Gonna have to continue sending customers to Amazon to get Ruckus at below my costs.
Take a look to cambium, project prices are great. Performance is top, service is top,
Switches and AP’s with same Cloud / lokal Config like Capsman. AX is available
I have beaten the hell out of their APs and they are not much better than Mikrotik. More inline with UniF–k performance. And get clobbered by Ruckus. No need to waste any more time on them.
The new WiFi 6 stuff was fantastically expensive when I talked to them a few months ago. And they are horrible about delivery vs announcement. I think I got my e600 2 years after the initial inquiry.
TP link have got wifi 6 on most of their latest offerings some with OFDMA and some with both OFDMA and mu-mimo.
All priced reasonably. Dont have any experience with them but do use the EAP245 which is a solid performing, stable version of what the current MTs should have been!!
Well, it´s about having a wireless package for testing, only. Let´s see whether 128MB of RAM is enough. Let us compare cAP ac with 128MB to older cAP ac with 256MB of RAM. Is there any limitation in a real environment? Who knows? Let us user check and report it back to MikroTik for getting a better wifi.
According to https://help.mikrotik.com/docs/display/ROS/WifiWave2 with WifiWave2 Mikrotik´s access points reach “400Mb/s maximum data rate in the 2.4GHz band for IPQ4019 interfaces”.
What about OpenWrt? What throughput do you get with 2.4GHz or 5.0Ghz with 20, 40 or 80 MHz channels? Have you tried “irqbalance” and enabled it by adding /usr/sbin/irqbalance to /etc/rc.local to improve throughput on your (was it cAP ac or hAP ac2)?
So, what iperf throughput do you get with 2x2:2 MIMO Up and down with 20, 40 and 80 MHz channels for 2.4 and 5.0 GHz? What access point are you refering to? TP-Link EAP620 or EAP660HD?
With OpenWRT on wAP AC (original), I get ~ 350mbps single client TCP throughput at MCS-9, 2x2, 80 MHz, WPA3. Device CPU is very close to 100% though which seems to be the limiting factor. Very happy with stability, every device “just works” and no weird throughput issues like MT wireless has with certain client chipsets. Looks like OpenWRT support for cAP AC (and presumably new wAP AC) is almost there, will be interesting to compare with a better CPU.
I just performed some tests with netbooted OpenWRT on hAP ac²: Even with performance cpu governor it actually performed slightly worse than my RouterOS 6.46.8 setup with capsman + local forwarding and secondary ssid.
The only real indication that there is unused potential on the hap ac² with RouterOS is the fact that single stream TCP iperf for iphone7(2x2)->hap_ac²->PC on close range is able to hit 470 Mbps, while the other direction cannot exceed 400 Mbps. OpenWRT was somewhere arround 350-370 Mbps for the same setup.
Real world performance is lower; tests with my RouterOS setup at speedtest.net result in around 300 Mbps download while the OpenWRT testrun for comparison was around 250 Mbps.
So my only expectation for wifiwave2 is to close the gap between up- and download, better real world performance and maybe slightly more stable datarates.
Well, it’s only when the hap ac2 is on the receiving end and only in 1-stream iperf. I guess it’s a best case scenario and I was testing at about 1m distance with clear line of sight.
I just wanted to point out, that the current ROS 6 only appears to be bad at sending wifi data at high speed (>300 Mbps), but when it’s on the receiving end performance is pretty much perfect. On my 1x1 Android device I get ~250 Mbps in both directions, it has been like that for me since the long-term 6.45 release.
If the current state of OpenWRT is representative of “real” wifiwave2 performance I wouldn’t expect huge benefits from it.
Edit: All tests performed at 5 GHz with 80 MHz bandwidth. Specifically I am using channel 116 Ceee, this is DFS/weather radar range but luckily DFS doesn’t trigger here.
