Thanks, exactly what I was looking for!
@hnyman, is or will this memory bump be available for r7500v2 also? My understanding is that these two devices are very similar.
See the pull request implementing it for the r7800, it really needs someone to do the very same tests (read above in this thread) for the other potential candidates.
https://github.com/openwrt/openwrt/pull/1003
While I could check the OEM firmwares for the other potential candidates as offered, it really needs someone to confirm it to be safe on the affected devices. While it's very likely that the r7500, r7500v2 and d7800 will behave the same, guessing wrong here in such a major invasive thing could mean bricking the devices in question - or at the very least to make reverting to the OEM firmware impossible.
I’m happy to do testing on my unit. Just need direction for accessing/installing the firmware.
does anyone test that using a device,which connect to r7800's lan port,as an iperf3 server,and r7800 as an iperf3 client,to test the speed
Slow ¯_(ツ)_/¯
Here is an iperf3 lan connected sample running on @hnyman master r7200 build with an HP laptop as a server and the R7800 as a client:
root@R7800RT1:~# iperf3 -c 192.168.16.196 -C reno
Connecting to host 192.168.16.196, port 5201
[ 5] local 192.168.16.1 port 33966 connected to 192.168.16.196 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 955 Mbits/sec 0 861 KBytes
[ 5] 1.00-2.00 sec 113 MBytes 947 Mbits/sec 0 861 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 0 861 KBytes
[ 5] 3.00-4.00 sec 97.3 MBytes 816 Mbits/sec 0 4.13 MBytes
[ 5] 4.00-5.00 sec 97.5 MBytes 817 Mbits/sec 0 4.13 MBytes
[ 5] 5.00-6.00 sec 105 MBytes 879 Mbits/sec 0 4.55 MBytes
[ 5] 6.00-7.00 sec 101 MBytes 852 Mbits/sec 0 4.69 MBytes
[ 5] 7.00-8.00 sec 107 MBytes 901 Mbits/sec 0 4.69 MBytes
[ 5] 8.00-9.00 sec 104 MBytes 868 Mbits/sec 0 4.69 MBytes
[ 5] 9.00-10.00 sec 104 MBytes 873 Mbits/sec 0 5.24 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.03 GBytes 885 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.03 GBytes 883 Mbits/sec receiver
iperf Done.Manage to fix and make the v13 led patch work... Should I push it? Lol
I set it to default on but i also tested other trigger and they work as usual.
Did you connect to router with physical switch? This performance almost as good as offical firmware. That's unlikely achived without hardware nat bro.
Yep, v13 works. I have been using that for a while, after I got the necessary fixes from @slh
Would be interesting to see if your working v13 contains the same fixes...
My build sources contain the original v13 patch, plus separately the fixes as a separate patch:
* 970-0001-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
* 970-0002-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets-kcompat.patch
Like you said, there has been no upstream activity for the LEDs for a while.
Might be sensible to try getting our local fixes into Openwrt until the ath10k upstream gets at least something. Slh's approach nicely provides path in future if the upstream driver gets in at some point.
@slh
Could you submit your driver patch, as that has so clearly the upstream v13 plus separately the Openwrt fixes?
There are also the device LED definitions, but those could maybe be submitted separately, and might be considered to changed from script-based to DTS based?
My idea was to revisit this now'ish, after the 4.18 merge window has closed and after kvalo had the chance to push his first post-merge-window pull request with upstream, and to provide a backport once these changes have been accepted upstream. kvalo has spent considerable effort to clean up the patch, so it would be sad to let it bitrot out of tree. Pushing the LED definitions into the DTS has been bothering me as well, it's definately a better approach, but I'm not really familiar enough with DTS to follow through.
Another topic, now that openwrt-18.06 has been branched off, would be looking into updating the backports package in general, as there are updated ath10k drivers needed to fully support the newer firmware ABIs (and VHT160 for QCA9984) released by QCA, I looked into a targetted backport for those, but that code is pretty much of an entangled mess.
Should i push also 2 additional patch that fix crash with 160mhz? (can't find if they just disable 160mhz or fix it)
This is the pull request... i think we should also include the 01_leds default scripts...
Direct lan connection between router and laptop. Router is supplying IP address to laptop via DHCP. NAT not needed.
root@OpenWrt:~# iperf3 -c 192.168.1.2
Connecting to host 192.168.1.2, port 5201
[ 5] local 192.168.1.1 port 38230 connected to 192.168.1.2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.02 sec 52.6 MBytes 433 Mbits/sec 0 210 KBytes
[ 5] 1.02-2.01 sec 51.2 MBytes 434 Mbits/sec 0 210 KBytes
[ 5] 2.01-3.00 sec 51.2 MBytes 433 Mbits/sec 0 265 KBytes
[ 5] 3.00-4.02 sec 52.5 MBytes 432 Mbits/sec 0 265 KBytes
[ 5] 4.02-5.01 sec 51.2 MBytes 433 Mbits/sec 0 265 KBytes
[ 5] 5.01-6.01 sec 51.2 MBytes 432 Mbits/sec 0 265 KBytes
[ 5] 6.01-7.00 sec 51.2 MBytes 433 Mbits/sec 0 265 KBytes
[ 5] 7.00-8.02 sec 52.5 MBytes 434 Mbits/sec 0 335 KBytes
[ 5] 8.02-9.01 sec 50.8 MBytes 430 Mbits/sec 0 416 KBytes
[ 5] 9.01-10.02 sec 52.5 MBytes 433 Mbits/sec 0 416 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 517 MBytes 433 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 517 MBytes 433 Mbits/sec receiver
iperf Done.
for me,it can't reach 500 Mbps
Is that latest branch fixed the 20Mbits cap bug?
What's your tcp congestion control?
My default is BBR, but also tried cubic still the same.
for me,bbr is very slow,use cubic reno or westwood can over 400 Mbps,but cannot reach 500 Mbps.
That's weird. I can reach 500Mbps on 4.9 with bbr default.
Need more feedback plz since some ppl can reach 1Gbps.