Overclock Merlin on v378.56 and beyond

[kvic]

Season's greetings to all tinkers and overclockers.

The following guide was in response to a request in one thread a while back.

https://github.com/kvic-z/goodies-asuswrt/wiki/Overclock-Asuswrt-Merlin-on-v378.56-and-beyond

Seems it will help more people as upgrades from 378.55 and older versions kick in.

May the force be with you.

 

[joegreat]

Season's greetings to all tinkers and overclockers.

The following guide was in response to a request in one thread a while back.

Hi,

Great idea and work to put the OC information onto a wiki page!

Two small enhancement suggestions:
- service-stop is another good place to have the OC set when doing reboots (as discussed here).
- it would be really beneficial to have the valid OC values in the wiki (below I contribute the ones for AC68U and N66U)

The force will be with you. Always. (part IV)
Joe

Spoiler: OC values for RT-AC68U

static unsigned int cpu_clock_table[] = {600, 800, 1000, 1200, 1400, 1600}
static unsigned int ddr_clock_table[] = {333, 389, 400, 533, 666, 775, 800}

Spoiler: OC values for RT-N66U

clkfreq=662,331,165

 

[kvic]

lol. services-stop was mentioned in the wiki dated 13 Nov..

Thanks for the youtube link

 

[RogerSC]

Season's greetings to all tinkers and overclockers.

The following guide was in response to a request in one thread a while back.

https://github.com/kvic-z/goodies-asuswrt/wiki/Overclock-Asuswrt-Merlin-on-v378.56-and-beyond

Seems it will help more people as upgrades from 378.55 and older versions kick in.

May the force be with you.

I recall hearing that the OC value (the value that you change "clkfreq" to) isn't effective when you do the nvram commit, it isn't effective until you reboot the router. But the new firmware overwrites the OC value on reboot. So even though the nvram variable would have the new clock value, it wouldn't change the clock frequency.

But I could be wrong, too...I hope so.

 

[kvic]

I recall hearing that the OC value (the value that you change "clkfreq" to) isn't effective when you do the nvram commit,

After nvram commit, the value is stored into nvram. What happens next are two scenarios from reports of forum members: 1) overnight (i.e. on a sparse but regular basis) the value is restored back to default. 2) right after reboot (i.e. CPU clock is ramp up to full speed), the value is restored back to default as part of the boot process.

it isn't effective until you reboot the router. But the new firmware overwrites the OC value on reboot. So even though the nvram variable would have the new clock value, it wouldn't change the clock frequency.

That's the reason we overclock the value in services-stop (thanks to Merlin's custom config - the greatest addition in Merlin firmware IMHO) right before the system is shutdown. No more chance for the firmware to restore to default.

Apparently if vendors want to lock the cpu clock, they might not have done in this amateur fashion so that we have chance to break the jail. We assume that the loss of ability to easily overclock is a side effect of NVRAM lockdown for RF related settings.