I have no answers nor am I informed about this; however I hope a question (not necessary to you) and some observations might help spark some discussion from others.
why not just bump the voltage and l2 "rates" to the max values (1150000 and 1200000000 respectively) and test? (i.e. if you could profile it, perhaps the performance degradation you observe is due to the changing values...)
My layman's knowledge of HPC is that there are several types of limitations one can hit. In this case, I'm thinking about cpu bound problems and memory bound problems. I suspect that the l2 cache performance enhancements would help memory bound problems while the performance benchmark your ran might be more of a test for cpu bound problems. Regardless, your benchmark test is still very relevant as it likely represents the most common use case for a router.
That said, maybe a different test is necessary to see a real change. I looked for a benchmark related to the l2 cache and came up with linpack but that might be too much work to port over. Stress is available on openwrt but I'm not sure which test to use or how to get some kind of benchmark from it.
HTH
EDIT: it would be nice to know if you saw a temperature change and/or a change in power consumption as well... i.e. is a mechanism to reduce the cpu freq starting to function if it gets too hot?
I used the performance governor and the CPU was running at the constant/max freq, so no values should be changing.
I ran the patched build for a few days with no temperature changes, but my router is running at <45C anyway. I didn't core about about power consumption, so did not measure that.
Hard for me to tell if the l2 voltage and rate are constant if the cpu freq is constant... but that would make sense
Wow, my ambient ranges between ~21 to ~26 deg. C and I see temp variations going from 44 deg. C (coolest zone, coolest ambient) to 54 deg. C (hotest zone, hotest ambient) running virtually no load with ondemand governor. You must have won the silicon lottery.
Not at all, I simply placed the router at a strategic location with ~15C ambient temperature and the router always runs with the performance governor. I just checked and the avg is ~40C.
I suspect the boot issue is related to how I got usb working. My repo has edits in qcom-ipq8064-r7500v2.dts tied to edits in qcom-ipq8064.dtsi to get usb working. I think you'll need to make "consistent" edits in qcom-ipq8065-r7800.dts (ty @slh) and qcom-ipq8064.dtsi (see @Ansuel's post above).
Note, my choice of labels and node names in these files is slightly different than what @Ansuel choose so be careful. I don't think it matters what label/names you choose as long as you are consistent; however, the "community" should decide soon to avoid this kind of confusion.
EDIT0: I did what I did because I can and I don't think many people care all that much what I'm doing... If I'm wrong about that, I'd be happy to update my repo for the r7800 as well. I don't have a r7800 so you'd have to test it.
EDIT1: I pushed a change to my repo for qcom-ipq8065-r7800.dts that you can try. For any R7800 user who might want to try, please search the thread for WARNING and read first. Test with caution. I believe a couple of other users have tried these changes on the r7800 but I don't know for certain. 4+ days up for me and no obvious issues.
Note, every time the kernel 4.19 patch is "refreshed" in the staging tree, I check for changes and update my repo using things like reset hard HEAD and reapply my patch set. Lastly, I'm currently not up to date with master due to the possible mac80211 issues mentioned above.
qcom-ipq8065.dtsi includes qcom-ipq8064.dtsi, so the generic parts needed for USB bringup under v4.19 are already done, what's missing are the (trivial) changes to the r7800.dts (tested on nbg6817).
Same symptom (won't boot)? If so try without the "ipq806x: k419 thermal sensors fix" patch if your willing.
Thank you for testing.
EDIT. I'm pulling out the thermal sensors fix patch from my k419 branch as this is my best guess for what might cause a boot issue (details here). I'd really like to know if you can boot without this but no worries if you don't try.
Hello friends, has any of this router's support changed since the first post of this thread? I would like to know if it has improved. I need an openwrt router with functional 5ghz wifi
@quarky will save us all, by porting all the code to 4.19, creating a patch with all hardware enabled that is accepted by owrt developers, and after that creating another patch to add the supported traffic shapers to sqm scripts and luci, that will then also be incorporated into master.
when that happens, this router soc will finally shine its true power and maybe I can forget buying a x86 for running openwrt at a decent speed with sqm enabled.
and obviously, lets not forget the amazing work also done by all the developers before, that made reaching this point possible.
What speed do you consider to be decent. The R7800 should easily handle 300Mbps with sqm. I know it doesn't with these releases here, as they contain several bugs which render this hardware useless.
Is this with the 4.19 kernel? The ipq8065 SoC should have enough grunt to do handle more than 140 with fq_codel qdisc. Could be a regression with the 4.19.
Have you tried with the 4.4.x lede-17-01.x releases?
I'm running latest master with kernel 4.14. I can do codel at 200mbps but not cake. cake tops out at around 140.
And codel at 200 is also near its limit. I think one of the cpu's ( the one dealing with the codel thread ) runs at around 90 % when shaping a 200/100 connection.
The only change I did to the master code was disabling the switch pooling stuff that was making ksoftirqd eat all the cpu, and I also run this on rc local:
