I would like to know if there is anything I can do to increase the IPV6 throughput over wifi. I have a number of mAP lites communicating through a "wAP ac" central router. The devices only communicate on IPV6, so I have them setup as a station bridge on the mAP lite to the central router. It's all working but my throughput is not as much as I thought over wifi specifically and curious why? Here are my tested speeds:
laptop <2.4g>wAPac<-rj45-> internet = 75 Mbit/s
laptop <-rj45-> device = 75 Mbit/s
laptop <-rj45->wAPac<-rj45-> device = 65Mbit/s
laptop <5g>wAPac<-rj45-> device = 26 Mbit/s
laptop <2.4g>wAPac<-rj45-> device = 16 Mbit/s
laptop <5g>wAPac<2.4g>mAP lite<-rj45-> device = 16 Mbit/s
laptop <2.4g>wAPac<2.4g>mAP lite<-rj45-> device = 8 Mbit/s
* I understand this gets cut in half because the data is sent twice through the 2.4G
from these tests I conclude the limitation is IPV6 throughput from my device through 2.4G wifi.
I can not find any more settings to improve it.
cpu monitoring is about 15% total, 35% worst case ever seen
IPV6 has fastpath enabled, no firewalls
IPV4 has fasttrack active with firewall, and I tried fastpath w/o firewalls
Running long term V7 routerOS, tried latest stable no difference
changed channel widths to 20MHz, set indoor/outdoor, checked wifi scanner to make sure no conflicts on 2.4G, plenty of other things.
Is this expected speed throughput with IPV6 traffic on wifi??
The throughput difference over WiFi between IPv4 and IPv6 should be virtually zero. Or, when measuring application throughput, IPv6 can somehow slower ... if using full MTU-sized packets, the difference will be around 1.5%, if using small packets (e.g. 200 bytes), the difference might be 10%. The difference is due to larger IPv6 headers compared to IPv4 headers (20 bytes).
When comparing "raw" WiFi speed, it doesn't matter which L3 protocol is used (either IPv4 or IPv6) because APs transport ethernet frames ... and thus doesn't care about L3 protocol.
You may want to check the registration table, it'll contain a few information about how devices are connected (both your AP as station to upstream and your WiFi client to your AP). Chances are that they will use "band 2ghz-n" ... which without using any advanced setup (such as using 40MHz channel) means maximum raw speed of 72Mbps. Realistic speed "over the air" is around half ... and if "air time" needs to be distributed between multiple devices and/or multiple virtual SSIDs, then actual transfer speed can be even lower. All of that with zero interference by other devices. So your numbers, as low they might seem, are perhaps what's technically possible.
So with everything you said, there should be no reason for such slow speeds. I have 2 ghz-n selected with 20 mhz, and that shows up in wifiinfoview as a maximum speed of 144Mbit/s. when I speed test my internet through that I get 75Mbit/s which is realistic speed of half like you said. So that's all great. But then downloading data from my device I still only get 16 Mbit/s when I get 65-75Mbit/s through straight RJ45. I assume there is something about this devices IPV6 data that makes it slow through wifi - but I don't know why or what I can do in the wifi to speed that back up. Not sure where to look to figure it out.
I'm not sure I understand the connection topology. The way I understand your explanation in the first post is this:
central router <-> "device" <-> laptop
And in worst case (8Mbps) both links "<->" are over the same 2.4GHz radio operated by "device", once as station (client of central router) and once as AP (serving laptop)?
In this case all traffic is passing same radio two times which halves the "realistic half" of theoretical maximum. In reality the reduction is even slightly more due to half-duplex and collision detection overhead ... and verify that both radio legs are actually running at 144Mbps radio rate. That would make throughput somewhere around 35Mbps... or less if one of legs is actually 72Mbps.
You're mentioning fasttrack ... since quite a few versiobs ago, ROS v7 does support fasttrack for IPv6 as well. But configuration to enable it, if carried over from older ROS versions, is not there. Look in /ipv6/firewall/filter for fasttrack rule similar to the one for IPv4 and if you don't find any, make one (similar to IPv4 fasttrack rule and similar to IPv6 accept established,related rule (if there are any particular properties set).<
However, I somehow doubt that missing fasttrack is the problem, I don't know any contemporary MT device, uncapable of routing at least few tens of Mbps without having fasttrack enabled.
For any further asistance you'll have to show device configuration (textual export) because I belueve you may have some error or unoptimized setting in the config.
I have just learned a little more about my device > it communicates on RJ45 as "full duplex" whereas wifi is almost always "half duplex" because the communication can not be two way at the same time. Makes sense.
End goal is something like this: laptop <5g>wAPac<2.4g>mAP lite<-rj45-> device
But the bottleneck even happens here: laptop <2.4g>wAPac<-rj45-> device
If I can solve the simple case, it would help me understand what's wrong. Device is a data logging acquisition module and communicates only on IPV6 data flow. I can get the end goal working but throughput is slow. The simple 2nd method above uses just one router and I still have the exact same bottleneck. I edited the first post with better test result layouts to make it more clear for you.
Happy to pay for your time in researching this issue, remote in, etc. It's not a firewall issue and it's not a CPU load limitation because I've verified that. Below is my wAP ac config:
I'm still confused. Configuration export is coming from wAP ac device ... which is not mentioned in your topology.
If it's router, then it's currently dangerous ... because it lacks any kind of sensible IPv6 firewall.
This device is capable of running wifi-qcom-ac driver (instead of wireless). The performance is much better, but it lacks a few features. More about it is in this document. Another drawback, not mentioned in documentation, is that package size is bigger than wireless ... and with tiny 16MB storage device, built in wAP ac, it might not fit. Or you might run into problems with newer ROS versions. Or neighbour's bunny might die. But if you will be using your wAP ac as simple access point (without much of other configuration, including firewall and what not), then it should be fine.
Also beware that wAP ac has directional antenna built in. The "best coverage" area extends in front of device at angle of roughly +-45°. If connected devices are outside this area, then signal strength from wAP ac might drop below usable signal strength ... or connected devices' signal strength is received at sub-optimal levels. In any case, throughput will suffer.
BTW, bridge priority setting is invalid. It should be set to value, which is multiple of 4096 ... or 0x1000 in hex. With default value on most bridges (various vendors) of 0x8000. Lower number being higher priority. So if you really have to deviate from default, set priority value to e.g. 0x1000 (but I don't see need for setting it to anything other than 0x8000 for now).
Sorry for the confusion! when editing the topology I mis-typed the central router as mAP when it's wAP as I stated in the paragraphs. I've fixed all my prior posts now so they are accurate.
This network does not have internet so there is no need for any firewalls. But those don't appear to cause any speed issues because I've tried the default ones and tried no firewalls. Yes the location of the antenna will be good, it's one of the reasons that model fits the installation so good. I will fix the priority on the bridge thanks for that.
Not sure if wifi-qcom-ac would work. It runs on the wAP ac but not on the mAP lite? So it's an advantage for 5G but not for 2.4G correct?
listed lost features of:
Compatibility with station-bridging as implemented in the 'wireless' package, station-bridge only works between the same type of drivers. Wifi to Wifi, and Wireless to Wireless.
I wish the mAP-52axD was released, that would really help me.