This is only a single speedtest and I am unsure whether this is over the OpenWrt ONE or the ISP router?
Could you also please remind me, what internet access capacity you have booked?
Why, if I might ask, typically the 5 GHz band is more performant.
That said, to compared things fairly you should likely set both radios to the same channel (and deactivate the WiFi on the device you are not currently testing, so they do not interfere with each other).
Finally channel 5 is unusual, have a look at this graph from wikipedia:
the goal is to distribute all radios onto non overlapping channels, and while in Europe the second scheme (1, 5, 9, 13) would be preferable, many devices default to the scheme 3 (1, 6, 11), use a WiFi stumbler (e.g. for android WiFi Analyzer (open-source) by VREM) and look at the channel graph to see which channels are used in your neighbourhood. The rule of thumb is, APs that partially overlap in the used channels interfere with each other by introducing noise, while APs on the same center channel fully overlap, but that means they can decode their frames (up to the encrypted parts) and hence can coordinate better resulting in better performance for all.
Hello , thanks for the info.
The speedtest is over radio0 of the openwrt ONE.
Only 2.4 because my laptop doesn't have a 5G driver. (I was too lazy I think, has now been adjusted.) Of course my android phone has both frequencies. Also adjusted the openwrt ONE: Radio0 on ch 4 and radio1 on ch 36, overlapping with the neighbors. Both the same SID. Reboot and still the openwrt ONE is much slower than the wifi ISP router.
Regards, Lucas
Other than that I added a few options (that should be orthogonal) this looks pretty similar.
Could you, please, check that you have all three antennas of the One screwed in snuggly? (Do not use so much force you would damage the threads, but make sure the antenas are not wobbling in the socket either)
First of all; I used US because the transmit power is 26 dBm instead of 20 dBm when using NL. I took largely over your wireless config with the change DE = NL 2x.
Unfortunately, the Openwrt ONE did not become faster, rather slower, too bad.
I had something weird with my OpenWrt One which I use as a bridged AP.
I noticed that one of the clients had lost connection to the AP. I had set he AP on 5Ghz channel 52, but somehow it changed to 56 by itself. After that the client did not connected any more.
When I restarted the interface and went back to channel 52 the client was connecting again.
I'm not sure what happened and how I can prevent it from happening in the future. Does anyone have an easy explanation for this?
Likely DFS (Dynamic Frequency Selection), that is your router caught a signal on channel 52 it could not rule out to come from a radar and hence was forced to evacuate that channel and select another channel.
Unsure, but it could be from trying to use too wide a channel on 56... I always tend to look at wikipedia for channel related information here:
Hi, M,
I got the openwrt ONE from the attic and connected it directly to the modem ISP. The shortest way out. That works a lot better, Now two switches are missing.
In the weekend I will try it out and compare it with the ISP wifi 6.
My download is 400 Mbit/s and upload is 40 Mbit/s.
Thanks you for helping me. I will be back
I tested the Openwrt One with the wireless of your German variant. It works fine now, thank you.
I am still curious about some options like the
option multicast_to_unicast_all '1'
option ocv '0' and
option iw_qos_map_set
are unknown to me and I did not see them in the wireless guide.
But fortunately it works reasonably now.
Regards Lucas
On WiFi if a packet is send as multicast (that is to all stations at the same time) typically the WiFi adapter uses the most robust modulation scheme so that all stations have a chance of receiving that packet (but that robust MCS/modulation scheme is also slow and consumes quite some airtime). So one way around this issue is to convert multicasts into a series of unicasts for all stations connected to an AP. Whether that helps or not, or whether it introduces issues depends on the details in your network.
I did not set this consciously, but according to:
it is the default anyways.
This allows to steer specific DSCPs into specific access classes (which have different priorities for getting access to airtime). My main goal is to make sure all non mapped DSCPs end up in AC_BE (especially DSCP decimal 45/NQB).
So what was the issue? Location, location, location of the AP in relation to the stations, or any of the slight configuration tweaks?
I am only getting 500-600 mbps out of my Openwrt One as an iperf3 client when running a wired test to my iperf3 server.
I have a Linksys E8450 (aka. Belkin RT3200) set up nearly identically to my Openwrt One and I routinely see 800mbps+ on iperf3 tests from my Belkin. The main reason I mention this is even thought it is not an identical SOC it is very similar.
My setup:
Both routers are running OpenWrt 24.10.1
Both are set up as dumb APs with all wired ports including wan assigned to br.lan (test is completely on my private network, no natting or traversing networks)
The one difference is I am using the m.2 slot on the Openwrt One to add 2 Nic slots. I am using: https://www.amazon.com/dp/B0BCXMGLYK and a 3d printed sidecar case. The drivers used is: r8168. This works beautifully and the ports seem to work as expected. That being said, the iperf3 test was run using the onboard 2.5gb port as the uplink to the switch that hosts the iperf3 server. Nothing is plugged into the r8168 ports during the test but the driver is loaded.
The nic speed or lack thereof is very disappointing. I was expecting at a minimum getting the same throughput as my Belkin 3200.
Please post your iperf output (ideally for tests in both directions).
Do you have receive packet steering enabled?
Also look at htop on the router while you run the test (enable the detailed CPU time in htop's setup, so you see SIRQ cycles as well) does one CPU max out?
Well, on the one, you appear CPU limited, so maybe install and activate irqbalance, or try to manually distribute the interruppts across the two CPUs...