I've seen Speedtest hit close to 400 Mb/s to the local to my city and ISP server (Cox), but I have such crappy interference I have to use a DFS channel to use Wi-Fi since no one else uses DFS. I probably could hit higher if I could have more than 23mW of power.
Link seems fine, so seems im limited by the cpu:)
975.0 Mbit/s, 80 MHz, VHT-MCS 7, VHT-NSS 3, Short GI
866.7 Mbit/s, 80 MHz, VHT-MCS 9, VHT-NSS 2, Short GI
I'm also on a DFS channel, however I have airport within 10km 
but so far last two days have been good,ddddddddd
Edit:
My nvidia Shield is almost getting 360mb's using 5g seems fine for me.
Zombie revive:
As far as I can tell, 980 MHz is the maximum stable frequency.
I tried 1GHz and I got conflicting numbers with iperf on client vs server. Around a ~20Mbps difference. These settings seem to work well:
iperf goes from 434mbps to 559mbps. That's with qca8k instead of ar8129.
I have not.
Worth trying but probably bumping core voltage might make it "stable" around 1 GHz.
Btw, I was never able to confirm stability of configured very high PLL and CPU/DDR clock/s (~900+ MHz) with scope, using CLK_OBS feature on GPIO (I was doing these measurements without changing voltages). Maybe it was a problem with just too high clock routed to GPIO line (and internally it was fine) but at the same time, stock clocks were looking fine. Either way, we are talking here about going with clocks outside spec, so anything could happen.
sure. for at least iperf, seems to be somewhat stable (1mbps difference between client/server).
@pepe2k Is that available within Breed GUI itself? Also, do you think there is a reason why the clock goes faster on a frequency > 1000 MHz? I am limited too by that barrier and my router stays at I think 960 MHz CPU.
It's pretty amazing to go from 720 to 980 honestly.
1 Like
what about the temperature of the router? have you had to add some heatsink?
So I have two Archers. One is a v2. It comes with no heatsinks. The v3 has heatsinks stock. The latter is a good candidate.
Both routers get warmer. But honestly ARM based units get much hotter to the touch. These get hotter but still warm to the touch.
1 Like
No idea, I don't think so.
It's probably because of difference in what you are settings in registers (and what the kernel reads from them later) and what you are actually getting in hardware. I believe the built-in VCO PLL has a limited range it works correctly in, anything above or below might give unexpected results. There is no way for the software running on overclocked hardware to tell whether the clock is correct, without comparing it with something proven to be stable and correct. That's why I was trying to confirm clocks with the the CLK_OBS feature on the external scope.
It will help for CPU OC.
What kind of diferrence does it make for DDR ?
With default voltage and CPU at 1GHz, after changing DDR range, my device started to crash few dozen seconds after boot. But with increased voltage it remained stable, even with CPU at 1.24GHz.
Is there a way to verify difference in DDR performance with changed range field value?
Any documentation about the regulator register ? So far, i was able to get +50mV or +200mV.
200mV seems too much or the regulator is not properly configured.
Update:
My REFDIV trick seems to fail for ar71xx. Seems 960 + 760 is the highest I can go.
edit: bumped DDR frequency to 800. works. 840 also works but is slower. Maybe if I bump CAS latency it would be more stable.
Oh, all of that really depends on your clocks configuration.
We are mainly focused on two separated PLLs, one for CPU and one for DDR clocks. But, you can actually run CPU clock from the DDR PLL or even run both clocks from a single PLL.
As far as I understand this field, it's something about selecting different target range where the PLL will operate in. Of course, for the O/C purpose, we are reaching far beyond the ranges mentioned in the datasheet but still, maybe selecting "higher" range would make the PLL work more stable/reliable? Dunno, really! 
I don't know if there is any relationship between CPU and DDR PLLs.
Have you actually confirmed somehow physically that your CPU is running at that clock?
I don't know any ready tests focused on performance, only on stability. But with higher DDR clock you should see higher overall performance, including network focused operations where a lot of data is transmitted between physical interfaces (e.g. PCIe to LAN).
I just found your e-mail in SPAM, didn't see it before, sorry for that!
No idea about QCA955x and QCA956x series (lack of enough hardware and... time), I was trying only with the old AR933x and QCA953x. I remember being able to manipulate the core voltage (AVDD 1.2 V) with 25 mV steps using one of the PMU registers from "PLL SRIF" registers group.
Here are some of my findings for QCA9531:
- bit 21 (PGM?) in PMU2 (0x18116c44), if set, enables AVDD voltage change (enables control over PMUs)
- bits 4~7 in PMU1 (0x18116c40) allow AVDD 1.2 V change in 25 mV steps
- bit 29 in PMU2 (0x18116c44) made the default AVDD 1.66 V and still allows 25 mV steps with PMU1
- bit 30 in PMU2 (0x18116c44) made the default AVDD 0.75 V and still allows 25 mV steps with PMU1
- be careful with bit 25 in PMU2, it made the overall device power consumption bump twice and... broke one of my testing device (I marked this bit as DANGEROUS in my notes)
Using different combinations of all of that I could get AVDD from 700 mV up to 2 V, of course with unbootable device with voltage near ends of this range.
Anyway, I just didn't have enough QCA955x based devices I could actually... sacrifice. I damaged few AR9331 and QCA9531 devices during my trial and error play. Unfortunately, these SRIF/PMU registers aren't documented at all, so it was a hard work trying tens of dozens different combinations with online voltage/current consumption/temperature measurements at the same time.
Only with software. For example:
Stream a single DVB channel using PCTV 461e card attached to router. The channel is running constant bitrate of approximately 18250 kbps - this can be seen in tvheadend status page.
Bitrate numbers are exact same with 720, 1000 or 1240 MHz CPU clock.
When set 1280 MHz tvheadend started to display about 19000 kbps, so pretty good sign of a clock drift.
Another way to observe is how much the boot time reduces in kernel log. When your last message is at, say 20 sec, and with increased clock it reduces to 19.2sec the OC looks good, but when it reduces from e.g. 18.5 sec to 15.6 sec its time to fire up stopwatch during next boot
QCA9558, Archer C7 v1.1:
- bits 19 and 20 (LDO_TUNE) in PMU2 (0x18116CC4) can increase VDD_DDR in 50mV steps
- bit 21 (PGM) in PMU2 (0x18116CC4) when set, bumped core voltage (AVDD12) from 1.21V to 1.41V - it wasn't fixed anymore and fluctuated with load changes, highest I've seen 1.62V, but it was useless as the errors and crashes I've previously seen at 1.2GHz now started to happen at 1040MHz. this change only has impact when PMU1 is at reset value (0x3009D8D0), if you write 0x633C8176 to PMU1 as the most u-boot versions do, then AVDD12 will remain unchanged regardless of the PGM bit
- setting PGM bit in PMU2 and writing 0x533C8176 to PMU1 (0x18116CC0) raised AVDD12 by 50mV, to 1.26V, dropped to 1.245V after boot, fluctuated with load up to 1.29V. OC is stable at 1.24GHz with this
1 Like
Interesting. So there isn't really a way to fix the clock drift then?
It is possible to extend OC range by increasing internal voltages or fine tuning regulator but as you go up with the clock you will run into drift again. Naturally, as the hardware has its limits.
As @pepe2k said, regulator registers are completely undocumented so its all blind guessing
Hello fellows,
one thing that we have to be mindful is the factory stock power circuit used low cost electrolytic capacitors that, in a few years will dry out, and is a major source of instabilities.
Especially under overclocking conditions, the introduced unstable current ripples can be exaggerated. (Verification with an oscilloscope is welcomed)
It is recommended that after a few years of continuous use, to recap them. Better yet, replace them with higher grade polymer capacitors, as shown below:
(Many thanks to the modder who helped me with the moddings)
With Metta
2 Likes
i just tried changing this on QCA9531 and it could set voltage up to 1.45V (didn't try other combinations to go higher than that) and then figured out since it was first information i found when trying PMU change on archer that i most likely missed PGM of PMU2 so i tried it on QCA9558 and it worked there as well.
but the archer doesn't do any better with higher voltage, drift appears above 1240MHz so probably PLL cannot go further on that one.
QCA9531 (TL-MR22U) was able to boot at 1320MHz (1.48V) and it looks like there was no clock drift, since i don't need that much on it i lowered it to 1100MHz as it can still cold-boot at reset voltage to that clock before PMU registers are set (i set it to +50mV)
1 Like