Overclock AC68U

[john9527]

I have a folder labeled jffs-20150407-5350

Just to solve the mystery.....at some point you tried running my NVRAM Save/Restore utility from the jffs directory. That's a backup of jffs from April 7th.

 

[snakebite3]

Just to solve the mystery.....at some point you tried running my NVRAM Save/Restore utility from the jffs directory. That's a backup of jffs from April 7th.

Thx for clearing that up. I was looking at my USB drive. I'm guessing the jff is something on the router. Using WinSCP i see a jffs folder in root. Is that where the script goes?

/jffs/scripts/services-stop

Is services-stop a directory I have to made?

Don't forget to set any script you create as being executable:
chmod a+rx /jffs/scripts/*

name it "chmod a+rx"? How do I go about add this code?

nvram set clkfreq=x,y
nvram commit

Do I simply paste that with notepad++ without the "#!/bin/sh"?

 

[texashoser]

There's no custom scripts on the stock firmware.

Yep. Just checking to see if anything had changed on the stock stuff. Did changes to the clock settings stick on older versions of the stock firmware? I could swear they did...

 

[RMerlin]

Yep. Just checking to see if anything had changed on the stock stuff. Did changes to the clock settings stick on older versions of the stock firmware? I could swear they did...

They did. Asus is now overwriting some nvram settings (such as the clkfreq) with the values stored in the bootloader. All part of the lockdowns required for things like the new FCC requirements.

 

[lepa71]

What is your default settings?

It was 800/666 I think

 

[oversim]

It was 800/666 I think

Even in "turbo mode ?

 

[Joe87t]

Sometimes I feel like why bother updating.. Nothing with Merlin at all as we know the FCC is the one doing this here.. But my device was absolutely flawless on .55, now on .56+ the overclock settings no longer stick and ive had a few bugs here and there where the router is online and operational, but i cannot connect to any wifi networks unless i reboot the box, which fixes it. But it seems like with every update, one more thing gets locked down negatively that wasent before... Almost seems like why bother updating, if it works fine and you get to keep your freedom, dont update lol

 

[lepa71]

I use John's fork 14E. Is there a turbo mode in it?

Even in "turbo mode ?

 

[john9527]

I use John's fork 14E. Is there a turbo mode in it?

Turbo mode only worked with the CFE/bootloader that was shipped at the router introduction. Since everyone had probably updated by now, the option was removed from the gui a while back. You can still use the nvram settings on the fork to overclock if you want to give it a try.

 

[lepa71]

I'm running it OCed. 1100/800. My wife and son complain that sometimes browsing is slow. So I don't know if I should downgrade to 1100/666.

Turbo mode only worked with the CFE/bootloader that was shipped at the router introduction. Since everyone had probably updated by now, the option was removed from the gui a while back. You can still use the nvram settings on the fork to overclock if you want to give it a try.

 

[john9527]

I'm running it OCed. 1100/800. My wife and son complain that sometimes browsing is slow. So I don't know if I should downgrade to 1100/666.

A couple of things.....1100 is not a valid value for the CPU clock....valid is 800, 1000, 1200, 1400 (don't use 1400). I think when I checked, if you set 1100 it would actually be 1200. Valid for the memory clock are 533, 666 and 800.

I don't think this would affect browsing speeds...not being able to support overclocked speeds usually results in hard hangs or router reboots. But you could always try resetting to 1000,666 as a safe value. Just FYI, it's usually the memory clock value that causes problems.

For the slow browsing, if it's over wireless, I'd look for a source of interference or try setting a different fixed channel.

 

[lepa71]

That what I was thinking. I will try 1200/666 and see. Thanks

A couple of things.....1100 is not a valid value for the CPU clock....valid is 800, 1000, 1200, 1400 (don't use 1400). I think when I checked, if you set 1100 it would actually be 1200. Valid for the memory clock are 533, 666 and 800.

I don't think this would affect browsing speeds...not being able to support overclocked speeds usually results in hard hangs or router reboots. But you could always try resetting to 1000,666 as a safe value. Just FYI, it's usually the memory clock value that causes problems.

For the slow browsing, if it's over wireless, I'd look for a source of interference or try setting a different fixed channel.

 

[oversim]

Hi guys,
Are you sure of an nvram set and nvram commit commands actually work without a reboot? I don't think so.. :-(

 

[oversim]

in other words..

admin@RT-AC68U:/tmp/home/root#  nvram set clkfreq=800,666
admin@RT-AC68U:/tmp/home/root# nvram commit
admin@RT-AC68U:/tmp/home/root# openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 7187815 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 64 size blocks: 1968598 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 256 size blocks: 510545 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 1024 size blocks: 128658 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 16130 aes-128 cbc's in 2.99s
OpenSSL 1.0.2d 9 Jul 2015
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
compiler: arm-brcm-linux-uclibcgnueabi-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -ffunction-sections -fdata-sections -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      38463.22k    42137.21k    43712.21k    43915.26k    44192.96k
admin@RT-AC68U:/tmp/home/root# nvram set clkfreq=1400,800
admin@RT-AC68U:/tmp/home/root# nvram commit
admin@RT-AC68U:/tmp/home/root# openssl speed aes-128-cbc
Doing aes-128 cbc for 3s on 16 size blocks: 7184400 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 64 size blocks: 1974451 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 511128 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 128827 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 16103 aes-128 cbc's in 2.97s
OpenSSL 1.0.2d 9 Jul 2015
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr)
compiler: arm-brcm-linux-uclibcgnueabi-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -ffunction-sections -fdata-sections -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      38444.95k    42121.62k    43616.26k    43972.95k    44416.09k
admin@RT-AC68U:/tmp/home/root#

 

[john9527]

Of course you have to reboot....what made you think you didn't?

The problem is that the nvram settings are being reset after booting by the code which locks down the wireless. The overclock takes place, but now nvram is reset. So you have to rewrite and commit it, so that on the NEXT boot it is re-applied.

 

[oversim]

Of course you have to reboot....what made you think you didn't?

The problem is that the nvram settings are being reset after booting by the code which locks down the wireless. The overclock takes place, but now nvram is reset. So you have to rewrite and commit it, so that on the NEXT boot it is re-applied.

Ok, but using latest merlin (or Asus) firmware, these settings are restored to their default value during reboot .. So, How can we overclock it?

 

[john9527]

On Asus stock firmware you can't....

On Merlin, you should be able to add the nvram set clkfreq and commit commands to /jffs/scripts/init-start
If you don't also manually enter the commands, the overclock will take effect on the SECOND reboot.
Verify with

cat /proc/cpuinfo | grep BogoMIPS

Confirmed in this post
http://www.snbforums.com/threads/overclocking-rt-ac56u.12578/page-17#post-214159

 

[bacon612]

Hi All. Longtime ddwrt 68u user here. Been recommending them for friends as they are really powerful routers.

In post #104, Merlin says that the latest CFEs have locked clkfreq built in preventing overclocking. Is this correct? I have dealt with two 68us both with the 1.0.2.0 CFE on them and am striking out trying to overlclock then for openvpn speed gains.

the following command is entered via telnet

nvram set clkfreq=1000,800 (tried 1000,666 too)
nvram commit
reboot

the router is back at 800,666 after reboot.

Do I have to downgrade CFEs from the CFE dump thread to OC these units?

 

[RMerlin]

The firmware is locking the clock, not the CFE.

 

[bacon612]

The firmware is locking the clock, not the CFE.

Understood. Thank you for clarifying that for me. So its on the ddwrt end that is preventing the overclocked values to hold.

Sent from my HTC One M9 using Tapatalk