Hi, I have been playing around with a Deco M4r running OpenWRT 22.03.2 as a Dumb AP.
DecoM4R is (5GHz)QCA98836connected to QCA9563 (MainSoC+2,5GHz) connected to QCA8337N
Basically an Archer C6 V2 with more ram, fewer Lan ports (2)
I followed the guide on the wiki, have dnsmasq, firewall, odhcpd disabled.
installed DAWN and wpad-wolfssl.
Now I notice that the Wifi throughput from Wifi to LAN is about half of what I get on stock firmware.
This got me wondering about the setup. All 4 interfaces (2 LAN ports, 2.5Ghz and 5GHz wifi; so all 3 QCA devices) are put into one BR-LAN. Also, in the Switch configuration, VLAN functionality is enabled.
Can anyone tell me, what does this mean for the performance of the device?
Does the VLAN functionality lower throughput? does the br-lan configuration?
also, is it even possible to disable vlan functionality in this usecase? I tried, but couldn't reach the device anymore.. (lost its dhcp assigned IP and stopped forwarding wifi traffic) if possible, how would I correctly re-configure the /etc/config/network without using vlan functionality?
currently:
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0.1'
option ipv6 '0'
config interface 'lan'
option device 'br-lan'
option proto 'dhcp'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0t 3 5'
Generally no. VLANs will not impact the throughput, and the bridge (br-lan) is necessary if both ethernet and radios will be active.
Can you be more specific about what your use case is? Devices with a built-in switch usually use VLANs for declaring the lan vs wan ports... if you're using a dumb AP configuration with no additional networks, you can certainly disable the VLANs, but it doesn't really serve much purpose (performance will not change).
What specifically did you change? from your partial config, I see you appear to have removed a few ports from VLAN 1, but there isn't enough info to know what you did and what you are trying to achieve.... can you elaborate on your network requirements/goals and current topology?
@psherman thanks for the reply.
So here is an overview of what the deco M4r looks like inside. The config parts I showed are the defaults (after I reverted everything).
only switch ports 0, 3 and 5 are connected. (hence the look of a partial config with removed ports)
What I tried to do was switch off the vlan functionality completely: first I tried to just:
untag port 0 (CPU), in
by setting:
config switch_vlan
option ports '0 3 5'
that didn't work. Then I tried removing the config switch_vlan block
under config switch: set "enable_vlan" to '0',
under config device: changed list ports 'eth0.1' to 'eth0'.
as mentioned, firewall and dnsmasq are fully disabled, I only had one zone "LAN".
so what am I trying to achieve? I don't know yet as mentioned, I noticed that the wireless throughput on the 5GHz interface is about half of what I got on stock firmware, and am trying to figure out exactly where the bottleneck is. I came up with a few thing:
The cpu is having additional work because it needs to tag/untag packets coming from/going to the QCA9886, before sending it to the switch. I don't fully understand if this is being done in HW or SW, but I guess it is at least done in the QCA9563, and not by the QCA9886.
2.The throughput is being hampered because of the WPA2 encryption not being done fast enough (again, not sure if done in HW on the QCA9886 or SW/HW on the QCA9563)
The ath10k drivers for the QCA9886 are just not good enough compared to whatever TP-Link is using
Some (other) problem with offloading either part of the Wifi protocol or moving data around between devices/ddr memory etc
So I figured disabling as much functionality as possible could get me looking in the right direction. Vlan functionality seemed easiest to disable...
I already tried overclocking the devices to see if that helped, but the improvements where marginal at best..
There will be no benefit whatsoever here. The tagging/untagging is handled by the switch chip itself, so the CPU is not involved.
This can be a few things -- ranging from the standard configuration options to the drivers for the wifi. It is not, however, related to VLANs at all.
Also, dnsmasq and the firewall have no impact here, either, because they are not going to see any traffic since you're setup as a dumb AP. The only thing you have to do is disable the DHCP server on the lan (the recommend approach is to set the interface to 'ignore'; disabling the dnsmasq process itself is not advised because if it is re-enabled, such as after a sysupgrade), the DHCP server on lan could become active again and cause problems on your network).
I would recommend that you reset to defaults, configure a dumb AP with the basic recipe, and then run some targeted experiments with the various wifi settings. I can be useful to know what settings/options you had configured on the stock firmware as a reference point.
For example, increasing the bandwidth from 40 to 80 give you a theoretical doubling of throughput, but at the expense of becoming more susceptible to interference (which is part of the reason that it doesn't really hit the theoretical doubling) and "clogging" the airwaves with respect to your neighbors). There are other optimizations you can make.
If you still can't get to the desired performance, search the forums for optimization of the QCA98836 based wifi (including possible driver replacements) and/or open a thread specifically on the topic of optimizing wifi on your device/chipset.
Thanks for your reply. I don't fully understand how that works in this case:
I understand that with the configuration '0t 3 5' the switch will tag all packets going out of the port0, untag them when going out of ports 3 or 5 (if they are tagged), in order for the cpu to understand which packet coming in from the switch is belonging to which VLAN (in my case always vlan 1).
but, the Wifi traffic is going moved between QCA9886 through the CPU towards the switch (and back). I assume that the packets send by the CPU towards the switch will then always be tagged (by the cpu?) and enter the switch as tagged packets. the switch then will untag them when sending out of ports 3 or 5.
or am I wrong here?
This is exactly what I did
btw also here, I figured as much (dnsmasq and firewall not seeing traffic), but still I read some pointers that using flow offloading (which is done as part of the firewall if I understand correctly) should help...
Yes also something I am playing around with. As far as I can tell I set up the wifi part similar to what stock firmware was doing.
thanks again, will look into the rest of your post.
Yes, the traffic is moving through the CPU in this case (since the CPU is creating the bridge), but the performance will be the same regardless of the status of tagged vs untagged packets. Tagging/untagging packets really has no impact on performance.
This is an area where I cannot comment with any authority. The flow offloading typically refers to routing, but it may impact other bridge activities. This is worth investigating.
as mentioned, I noticed that the wireless throughput on the 5GHz interface is about half of what I got on stock firmware, and am trying to figure out exactly where the bottleneck is. I came up with a few thing: