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.
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.
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.
Cc: @matthijs
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
on 5GHz:
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.
Much appreciated. I'm positively surprised that soft flow_offloading gives so much benefit.
@Dock
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.
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!
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.
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.
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, /proc/cpuinfo says 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 ethreg or devmem (eventually /dev/mem) is present?
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)?