I’ve got next scheme:
HAP ac - is using as Wi-Fi router only (only IP address for mgmt)
Client1<->AP(wlan2-5)<->Client2 - all of them located on the table distance 0.5m
Both of the clients have 2*2 MIMO.
I’ve tried different regulatory-domain, as well different 5GHz settings.
Also tried version 6.44.6 (long-term) & 6.45.7
But speed <= 150 mbit
Well, as i can see only 20 MHz channel width is used which makes that speed pretty normal… I guess your client devices do not support greater channel width ? Am not sure if thats the case though…
You could play with the VHT rates, you could try another frequency and lastly, no need to have the clients so close to the AP…
Thanks for your answer.
In my case I turn off/on Wi-Fi and had 20MHz wifi
Both of my devices had ac support (you can check my post) intell wi-fi card 22 and second one is OnePlus6 phone with 22 MIMO support.
What can I test more?
Some ideas?
Thank you.
When I did some testing when I received my hAP ac2, I noticed that in DL AP would use quite considerable amount of CPU during intense traffic (not that much in UL so regularly I’d experience better throughput in UL than in DL).
Another observation was that it behaved differently if I tested using multiple parallel streams but not too many (e.g. 4 parallel streams gave significantly higher total throughput than single stream, 10 streams however made AP struggle). This might be caused by multi-core architecture of ARM CPU in hAP ac2 though. When same iperf client and server were tested via 1Gbps wire-only, they could saturate link with single stream just fine. Another thing when testing high-delay[*] links is to use UDP streams for tests, it shows media throughput better.
And keep in mind that RBD52G (hAP ac2) has CPU which is a beast compared to the one in RB962UiGS (hAP ac).
[*]this is not an absolute quantity, it depends also on bandwidth of a link. However, with multi-100Mbps links, I consider any RTT delay higher than 10ms to qualify as high-delay link because RTT that long easily affects performance of TCP due to ACK/NACK scheme and window size and slow start and what not. Using several parallel streams alleviate the problem to certain extent because all those streams reduce available bandwidth to each other quite signifficantly while increasing RTT only slightly (i.e. 10 streams reduce bandwidth available to each stream by factor of 10 while RTT might increase only by 50% due to TCP’s inherent flow control mechanisms).
The timing might interfere with some OSs’ IP stack differently than other OSs’ … I’ve encountered cases when testing against Linux server gave quite different results than testing against Windows server even though ping returned similar RTT times. And it wasn’t any rule which server OS gave better results at given test conditions.
WiFi is a shared medium, and both clients are connected wirelessly. So, I’m not really surprised by the outcome. How did you use iperf, did you use single stream or multiple streams?
I tested with multiple streams & single stream as well (TCP & UDP). Made a screenshot of CPU when I tested Wi-Fi speed.
I know that wireless doesn’t equal wire.
But for both of devices which have 2*2 I expected up to 500Mbit
I bought HAP ac hardware to get not 150Mbit/s (for this speed I have my previous Wi-Fi)
I tested with FTP, copy files and also iperf = same result.
The most confusing thing that AP shows that this devices can utilized bandwidth.
I’ll get my laptop & phone to test speed with another Wireless AC solution.
Static channel doesn’t help.
Also my friend have HAP ac test speed of 5GHz between 2 Macbooks and have the same result.
I don’t want to test this at all I just want this to work.
Do you have any ideas?
Maybe someone have HAP ac and the same problem?
You test the hap ac2 with 2 connected wireless, which splits your bandwidth, so 150Mbit is in fact 150Mbit IN and 150Mbit OUT from hap ac2 all on same channel
all wireless devices located so close together are making a lot more noise = lost bandwidth.
From what I know, the default iperf packet size is small (16bytes?) and all networking will benefit using a larger packet size, let’s say 512 bytes or 64 bytes as in https://mikrotik.com/product/hap_ac2#fndtn-testresults
You should make the test between wireless and cable to see a result not influenced that much by the interference of the other devices.
If your use scenario does involve transferring data over two or more wireless devices connected with a hap ac2 in the real world, then start from the maximum THEORETICAL throughput of all devices and will have about 25% to 30% in good conditions. So if you want 500Mbit between two wireless devices connected to an ap, you should have ALL devices with support for 1300Mbit over wireless. You have 867Mhz Intel so you should expect about max 300Mbit not 500Mbit in real life.
