Do you have this router? I experience poor download speed on the 5GHz radio. It drops to 6Mbps on 20MHz when connected. Upload is as expected. V1.002 is the one I have.
I think it is driver related, but I'm not experience enough to try and test different drivers, firmware and settings for the 9882(x) radio.
Can you check yours if you have one?
I have two of them running, but I have just put them up and did not really test performance. I also used the same SSID for both 2.4Ghz and 5Ghz, so I didn't really test them separately.
I'll see if I can find a moment to test this when I'm near these routers again (might be a week or two), to see if mine also has limited performance on 5Ghz.
Thanks. Looking forward to your results!
BTW, this behavior does occur in SNAPSHOTS from about December to today.
I did a quick test today. On 5Ghz, the link speed stuck to 80-90Mbps, but the actual speed of an HTTP download was about 80-160kByte/s, so not really great. Looking at a wireshark dump I saw that there was some downlink packet loss (one in 20/30 packets or so), so that probably limited the downlink speed by limiting the TCP window.
I did another test on 2.4Ghz, which stuck to 54Mbps link speed, but the actual download speed was still only 200-300kByte/s.
I do have some other problems with link speed on this particular laptop though, so I'm not sure if this was a super representative test...
I tested the current SNAPSHOT today and the speed of the AC radio has improved. But not as it should.
However, there is an issue with throughput of the WAN-LAN ethernet speeds. It is not going above 2-4 Mbps. So there is an issue in the switch driver or in the chipset dirver itself? I'm not "qualified" to judge...
Is there anyone in this thread reading along to verify what's going on with this Sitecom Router? I have three WLR-8100 routers running smoothly, but this little brother is crippled since a couple of months.
In my tests the WiFi throughput was realistic (download tested only), on 2,4GHz:
laptop with AR9382: 3,42 MB/s (rather on the low side)
Xiaomi A1: 4,26 MB/s
laptop with AR9382: 8,92 MB/s
Xiaomi A1: 21,9 MB/s
The wired WAN to LAN download speed was around 22 MB/s. When I used "iperf3 -P4" with laptop and pc connected to each zone, the throughput was around 160 Mbit/s, with flow_offloading enabled the speed jumped to 193 Mbit/s. This is rather low for such device, I would expect 150 Mbit/s more. Looks more like the connection between CPU and switch is limited to 100 Mbit/s full-duplex, but I did compare switch registers with original firmware and those are exactly the same.
I'll try to redo the tests in upcoming days and check if I did something wrong.
@musashino Hi, You committed support for I-O DATA WN-AG300DGR router and it appears very similar to WLR-7100. Could You test the wired speed (WAN to LAN) with "iperf3 -P4" on latest OpenWrt snapshot? Thanks.
Hi, I tested on I-O DATA WN-AG300DGR (WAN to LAN).
config switch_vlan <-- lan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 0t'
config switch_vlan <-- wan
option device 'switch0'
option vlan '2'
option ports '1t 2t 3t 4t 5 0t'
firewall rule for the testing:
option src wan
option dest lan
option dest_port 5201
option proto tcp
option target ACCEPT
I will check again with the current SNAPSHOT.
Could Luci slow things down? Memory is barely enough to have that installed.
Much appreciated. I'm positively surprised that soft flow_offloading gives so much benefit.
Yes for wireless, as each client increases the memory usage (ath10k occupies a lot for each client). Shouldn't for wired, but in tight memory environment could.
cc: @tmn505 and @matthijs and @musashino
My results with the SNAPSHOT of 24 April 2021:
Fresh install, default settings (no LUCI): WAN->LAN:
DL 11.30 Mbps en UL 3.90 Mbps. Used to be my max fiber speed (around 100 Mbps up and down) with older OpenWRT firmware.
Installed LUCI and enabled software offloading. Results WAN->LAN
DL 16.61 Mbps and UL 2.35 Mbps
WiFi at default settings, just enabled.
WiFi 2.4 DL 11.8 Mbps and UL 40.8 Mbps (iPhone 12 mini)
WiFi 5.0 DL 19.9 Mbps and UL 94.4 Mbps (iPhone 12 mini)
Software offloading does not have a significant effect on the speeds.
I still have another WLR-7100 (v1.001) with SNAPSHOT r14256-a69949a13f:
Ath10K firmware-qca988x-ct 2020-07-02-1
kmod ath9k 5.4.60+5.8-1-1
kmod ath9k-common 5.4.60+5.8-1-1
kmod ath10k-ct-smallbuffers 5.4.60+2020-06-30-edfbf916-1
This version of OpenWRT is fast on WAN->LAN (offloading disabled) and has fiber speeds (around 90 Mbps) on the 5G WiFi. Luci installed. This router IS capable.
I suspect around December 2020 some changes in the drivers or switching did not work out very well for this router. It is very capable when configured properly.
I'm not so familiar with building own firmware, but if I can be of help with fixing this and even get this device to the stable release I would gladly make some time for that!
I installed the stable release today and the issues are present as in the latest SNAPSHOT.
Very slow wired WAN -> LAN and DL on 5ac WiFi very slow.
Happy to see the WLR-7100 made it to stable release. Next is to get the transfer speeds up to specs. Who is the dev that knows this device best?
Hi, first time on openwrt. I have this kind of router (wifi is bad and often disconnected devices).
I want to know if is it possible to install a stable release directly from Toolbox/Firmware.
or then if it is better to buy a new router?
Thanks in advance
I found the issue. The current stable release 21.02 works perfect on the WLR-7100 v1.001. But on the v1.002 it has a very poor download. Even wired. In suspect the chipset is a different revision.
I will look inside to check for any differences. Would that be of any help for the devs?
If you have v1.001 you may safely upload the dlf version of OpenWRT 21.02 to this device. It will most likely run perfectly, as mine does. The v1.002 version of this router behaves differently in my case. The download, both wired and wireless does never exceed 10Mb/s. While upload is on par with v1.001. Still have to figure out if it's just my router or all WLR-7100v1.002 are affected.
Does this help 4 months later?
I have both versions, and have been using the v1.001 with the v1.002 on the shelf for the past two years or so. To upgrade my router, I configured the v1.002 with a newer firmware and replaced the entire router, but ran into poor performance problems. I first suspected firmware changes (not realizing I had two different versions), but I downgraded the v1.002 to the same firmware as v1.001, and the problem persisted. I have not yet tried upgrading the v1.001 to the latest firmware (since that is currently running my organization's network, so I'm reluctant to risk breaking my only working setup), but it seems indeed that v1.002 is slightly different and thus OpenWRT has bad performance on it, just like @Dock also described.
@Dock Do you happen to have pictures of the v1.001 for comparison? I put pictures of the V1.002 on the wiki, but cannot easily open up my v1.001 now.
As for further debugging:
- I have found that the root cause seems to be dropped incoming packets. I've seen 1% -15% depending on circumstances.
- I've seen this happen on both WAN and LAN.
- Setting up port mirroring on the internal switch suggests that the packets pass through the switch properly, but get lost before or in the CPU ethernet interface.
- I've seen this happen with HTTP, scp, but also simple pings. The easiest way to reproduce this is to just ping the router:
ping 192.168.2.1 -s 1400 -i .01. This uses a high interval, so you can see the problem without having to wait for a long time, and bigger packets since that also seems to increase the packet loss percentage (but not linearly). However, the problem is also visible with default 56-byte packets and 1 second interval, so it does not seem to be a packet size or packet rate issue.
- On the recent 23.04 release, I get about 1.3% with 56-byte pings, and 13% with 1400-byte pings. However, on some old snapshot version (r15249-85caf21ade, kernel 5.4.83) I get about 0.2-0.4% with 56-byte pings, and around 2% with 1400-byte packets, so it seems the problem did get worse in recent versions.
- I suspected that only incoming packets were affected, because e.g. outgoing file transfers were fast while incoming were slow (outgoing file transfers would then still have dropped ACK packets, but those are smaller so less problematic). If this were true, however, then an outgoing ping would see the same amount of packet loss (replies would get lost instead of the pings), but that does not seem to be the case -
ping 192.168.2.191 -s 1400 gives me 0 lost packets (out of 400 tries, busyboxy pin doesn't support < 1s interval). Using
-A (next ping as soon as previous reply is reached), I see 10 out of 4000 packets dropped, so maybe the problem still exists but is somehow even less likely to occur on reply packets? Running longer with 1s interval I see 2 out of 500 packets dropped and later 3 out of 4000 packet.
- The stock firmware is the same for both hardware versions (both versions have their own download page and different filenames, but are byte-for-byte identical). Maybe the firmware source has a hint about what is different between hw versions, but I have not investigated yet.
On other interesting detail: On v1.001,
system type: Atheros AR9342 rev 3
and on v1.002 it says:
system type: Atheros AR9342 rev 1. So this confirms a previous suspicion that these versions use a different revision of at least the SoC (interesting that the newer router version has a lower SoC revision, but maybe there's some revision register weirdness going on there), though it is unclear if the problem is related to a change in SoC revision, or maybe there is also a PCB change.
I've tried to lookup the revision history for this SoC, but I couldn't find a datasheet for the AR9342 at all (I could find 41 and 44 here). Also, the actual chip is marked AR1022, but I suspect this is the old atheros name for the Qualcomm-Atheros AR9342 (suggested by this wiki page as well). It's a bit weird that I can find hardly any mention of the AR1022 chip at all, though, so certainly no datasheet either...
These are very nice findings, the differences in SoC revision could explain the problem. Could You test if packet loss occurs if 100Mb/s or 10Mb/s is used. If not, then probably 1Gb value from
pll-data is wrong. But if the losses are also there, maybe we need to add delays in dts
gmac-config node (https://git.openwrt.org/f3ffac90bc). The values can be from 0 to 3. For elaborate description check datasheet AR9344_May_2012.pdf (they float on GitHub) paragraph 9.7 and 11-3, 11-4 tables.
Do You still have vendor firmware on v1.001? Could You check if
/dev/mem) is present?
Hi, nice see this re-opened...
I will take pictures of both v1.001 and v1.002 this week.
I also have different strange behaviour of the v1.002, which made me decide to stop using the device: it seems to run out of memory when trying to upgrade with Sysupgrade. I just hangs while uploading the file... only once in a lot of iterations reaching 100%. The v1.001 always uploads new firmware in a steady velocity.
Any of you also using the WLR-8100 (both versions)?
Both have the AR1022-AL1A,
but the V1.001 mentions additional PCK912.00B 1139
and the V1.002 mentions PCS681.00B 1146
The v1.002 is poorly readable, only with light in a specific angle.
Does this help?
Tested AC speeds on both with 23.05.0-rc3:
V1.001 reaches max (around my max WAN fiber speed of 100 Mbps) and v1.002 maxes on 38Mpbs downstream. Upstream both around 100Mbps.
Issue not as bad as years ago but significant. Uploading of firmware still struggling but doable.