Overclocked kernel - Tests

Search This thread

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
This old thread refers to the old overclock hack (look at the date it was posted!) that only modified the frequency table, not the PLLs. The new one modifies the speed of the running PLL and seems to work!

To put an end to all of this overclock speculation among the community, I've decided to do a series of tests to either prove or refute the effectiveness of the recent overclock patch. Most, if not all, of the developer community has already stated that the patch is not effective, but from what I'm still hearing, many in the community still believe that it is. The purpose of this thread is to offer some hard numbers, and to explain exactly why.

I used OpenEclair v1.0.1 as a ROM, with the overclock kernel up to 780MHz. I did three trials at each speed per benchmark. The values you see are the average of three trials. Everything was kept as consistent as possible between all the benchmarks - same ROM, same number of background applications running, etc. After setting, each speed was verified using BogoMIPS and scaling_cur_freq.

Though I'm pretty confident that the patch isn't technically doing anything, I documented benchmark results at several speeds to verify it. For the first two benchmarks, I did 10 trials, counting the first five, and throwing out any outliers (likely indicative of a temporary boost/slowdown in the system) for results in the other five. Each app was given time to "settle" after launching.

Benchmark 1
Benchmark 1 was done with Linpack benchmark, available on the Android Market. The higher the score, the better.

384MHz: 1.627 Mflops/s, 1.703 Mflops/s, 1.709 Mflops/s, 1.7 Mflops/s, 1.713 Mflops/s
Average: 1.6904 Mflops/s

528MHz: 2.31 Mflops/s, 2.318 Mflops/s, 2.306 Mflops/s, 2.288 Mflops/s, 2.308 Mflops/s
Average: 2.306 Mflops/s

628MHz: 2.263 Mflops/s, 2.279 Mflops/s, 2.278 Mflops/s, 2.301 Mflops/s, 2.309 Mflops/s
Average: 2.286 Mflops/s

780MHz: 2.286 Mflops/s, 2.288 Mflops/s, 2.281 Mflops/s, 2.278 Mflops/s, 2.277 Mflops/s
Average: 2.282 Mflops/s

The values beyond 528MHz are actually slightly lower than the values at 528MHz, but I do not believe the difference is statistically significant. For Linpack, these results are pretty much the same across the board.

Benchmark 2
Benchmark 2 was done within SetCPU. SetCPU uses a very simple benchmark, running thousands of calculations in Java, then determining how long it took to do those calculations. It is meant for comparing different CPU speeds across the same device. The lower the score, the faster. My own benchmark, within SetCPU, seemed to fluctuate the most between results (I should work on that). :p

384MHz: 937.0ms, 948.0ms, 940.0ms, 940.0ms, 939.0ms
Average: 940.8ms

528MHz: 712.0ms, 707.0ms, 704.0ms, 708.0ms, 705.0ms
Average: 707.2ms

628MHz: 711.0ms, 713.0ms, 709.0ms, 703.0ms, 704.0ms
Average: 708ms

780MHz: 707.0ms, 709.0ms, 715.0ms, 688.0ms, 706.0ms
Average: 705ms

Benchmark 3
Benchmark 3 was done with BenchmarkPi. Again, the lower the score here, the better. Because of the length of this benchmark, only six trials were taken. The lower the score, the faster.

384MHz: 18646ms, 18246ms, 18313ms
Average: 18402ms

528MHz: 13206ms, 13124ms, 13204ms
Average: 13180ms

628MHz: 13217ms, 13290ms, 13200ms
Average: 13240ms

780MHz: 13327ms, 13321ms, 13283ms
Average: 13310ms

What can we conclude here?
The differences between the higher three frequencies above are within a few percentage points of each other at most, and are too minute to make a difference. There are no statistically significant performance benefits when overclocking using the recent kernel patch, at least as shown by the three independently developed benchmark tools used above.

What's actually happening here?
The kernel is being told by the CPU frequency table that it can set CPU frequencies that it doesn't support, and thus, the kernel "thinks" it's on a higher speed, but in reality, it isn't. No actual frequency changes are occurring beyond 528MHz. Though "BogoMIPS" in /proc/cpuinfo was previously believed to be a measurement of CPU speed, and not calculated from what the kernel thinks is the current CPU speed, we now know that it's a derived rather than measured value. Thus, CPU frequency scaling applications, which rely onthe values the kernel provides, will be fooled too.

Technical details
CPU frequencies on the MSM72xx are all derived from what I will call "master clocks," or formally, PLLs. These PLLs run at set frequencies and cannot be changed. In order to get a valid CPU frequency, you must divide one of these PLLs by a whole number.

The available PLLs are:
PLL2: 1056MHz
PLL1: 768MHz
PLL0: 245.76MHz
TCXO: 19.2MHz

As you can see, by dividing some of the above numbers, you can derive the commonly available frequencies of the MSM72xx. 1056/2 = 528MHz, 768/2 = 384MHz. There are also possible frequencies, such as 352MHz, that can be derived from the above PLLs, but are not in use in current kernels. A lot of these frequencies are declared in the kernel source, though.

In order to run faster than 528MHz, we would have to derive a faster frequency from either 1056MHz or 768MHz. The next step up would be 768/1, or simply 768MHz. Daproy and I have both tried the relevant kernel mod and this crashed both of our phones. He also posted a boot.img and kernel patch for others to try (the usual disclaimers apply here).

On MSM72xx Turbo chips (used by the Hero, Tattoo, Galaxy, for example), PLL1 is running at a faster frequency (960000, or 960MHz). This means that instead of 384MHz, these chips have 480MHz. Update: the MSM7227 series seems to run PLL2 at 1200MHz, which is why they are capable of running at 600MHz.

The current overclock patch is keeping the divisors at 1056/2 - when the CPU is told to run at those settings, it will divide PLL2 by 2 and run at 528MHz. The kernel, however, is told that it is being run at a higher speed (where in reality it is not).

So, you still want faster speeds?
There are some possibilities to reaching faster speeds now. Here are some of the current ideas.

- The most obvious option would be to adjust the speed of the running PLLs. This would be difficult to do - I believe that the PLLs are set in the radio firmware. A badly modified radio will brick your phone on contact, so it's likely that not many would be willing to test a modified radio. If we adjusted PLL2 to run higher, we could make the 528MHz clock run at a faster speed (slower and more stable than 768MHz, but faster than 528MHz). This has been attempted by at least one individual on an Android platform, the other on WinMo, with no luck yet. damnoregonian believes that this is because the PLL speed is designed to be changed by the ARM9, and thus cannot be changed by the kernel.
- The more dangerous (bar flashing the radio) option would be to try to increase the voltages going to the CPU in order to make 768MHz more stable. Almost every overclocking effort thus far (Droid, Nexus One) has required a voltage increase beyond a certain point, and the MSM7k is probably no different. The problem is the kernel does not give us the ability to fine tune voltages like it does on other platforms. This also involves low level work.

These are my results, and you are free to run independent tests of your own. I recommend running many trials, and setting the CPU governor to "performance" to keep scaling consistent throughout the trials.

Do not blame eugene or any kernel/ROM developer. I just as easily believed this at first - is a very exciting prospect. I even gave out instructions on how to make these frequencies work in SetCPU. I, like many others, thought that BogoMIPS was a real measurement rather than a calculated value from what the kernel thought was the CPU speed. This post was purely meant to inform the community. Let's keep making our phones better.
 
Last edited:

oreoOozZz

Senior Member
Nov 13, 2008
725
27
Aww shucks, just when it was getting good. :p

Thanks for all the hardwork coolbho, now we can all finally put this matter to rest.
 

engagedtosmile

Senior Member
Mar 28, 2009
522
8
I am thankful for this thread. I too was excited when I first heard of the overclocking but quickly became skeptical. Thanks for this and thanks for SetCPU.
 

mnissan

Member
Jul 1, 2007
41
0
Although I'm sorry to hear this, I must say I admire the work thatyou've done here, thank you.
(Feel free to give me a call if you need a multiple ANOVA done on those test results, or even just an f-test :) )
 

Brainze

Senior Member
Jan 25, 2008
514
28
Somewhere Near ATX
In different Layman's terms for those who still don't get it...

This is like putting one of those "Tornado" thingies in your car's air intake...

This is like duct-taping a broom to the back of your vacuum...

This is like adding herpes to someone who already has genital warts...

It's NOT effective... :D
 

oreoOozZz

Senior Member
Nov 13, 2008
725
27
In a different Layman's terms for those who still don't get it...

This is like putting one of those "Tornado" thingies in your car's air intake...

This is like duct-taping a broom to the back of your vacuum...

This is like adding herpes to someone who already has genital warts...

It's NOT effective... :D

clapping-hands-lg1.jpg
 

Firerat

Senior Member
Feb 24, 2009
3,848
185
:) I came to same conclusion with this ugly but simple script

make a 10 meg file
Code:
dd if=/dev/urandom of=10meg bs=10 count=1024k

uninstall/disable your current cpu OC apps
you may also want to turn off data sync

one 'loop' will take around 10 min ( bit less )

Code:
for cpufreq in 128000 245760 384000 528000 550000 560000 570000 580000 590000 600000 628000 650000 660000 670000 680000 690000 700000 728000 750000 760000 770000 780000
do
echo $cpufreq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo $cpufreq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
#for loop in 1 2 3 4 5
# remove # from above and delete line below to loop 5 times at each freq 
for loop in 1
        do
BogoMIPS=`grep BogoMIPS /proc/cpuinfo|cut -c 11-|sed s/\ //g`
time gzip 10meg 2>&1|sed s/^/gzip\ loop$loop\ $cpufreq\ $BogoMIPS\ / >> cpubench
time gunzip 10meg.gz 2>&1|sed s/^/gunzip\ loop$loop\ $cpufreq\ $BogoMIPS\ />> cpubench
        done
done
echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 245760 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

now take a look at cpubench
cat cpubench
you may like to filter, e.g.
cat cpubench|grep gzip|grep real|less
use <space> or ball to scroll through ( q to quit )

not going to say that this is the best way to test performance, but you may find the results interesting

if needs be I'm sure we could come up with a script of formula instead of gzipping random junk
 

ralle.gade

Senior Member
Sep 13, 2009
216
1
Anyone who knows how to really work with radios and editing them? Could they please pm me, as I would like to actually try this regardless of bricking!
In advance thanks :)
 

Klyentel

Senior Member
Aug 23, 2009
826
132
Cary, NC
bit.ly
Well alright then,
not too much I didn't already know...but must say I've learn something.

Anyway, So sounds to me like we're not that far away....

I'm on a market for a new phone, its $600 bucks stashed in my savings thats been burning my pockets, I'm only procrastinating in hopes some amazing new android phone will release from T-Mobile, and blow everything off the market, nothing happened, on top of that I'm hesitant about retiring the G1....

But heres the deal, if one of you devs work up a modified radio that you think has at least a fifty/fifty chance of working, I will flash it.

Yes I am aware that it could be a suicidal mission for my Dream, rending the poor thing useless as a Brick.
That'll just make me get off my butt and get a new phone which is what I've been saving for anyway,
when someone's got something post me the link, and I'll do it, for me, and for the community:D
Hopefully we get a good result with REAL unquestionable over clocking speeds in the 700's or I'll just throw my Brick in the closet in hopes that the Jtag mission can revive it one day, who knows.

Meanwhile, I'm going to continue enjoying my super fast speed with my super D rom, using my fake over clocking patch, having fun with all of this fake increase of performance, that I've been enjoying oh so REAL!:D
you don't like it? Fine. Waste ya time posting how I'm in G1 denial, and that my CPU speeds are useless and aren't increasing anything...and blah, blah,blah. Lmao, As if I didn't know already. whatever it is not doing, Im sure glad its not doing it, because its doing great!:)

Peace love and Prayer for the G1 Community!!!;)
Don't worry guys things are only getting better
 

TeeJay3800

Retired Forum Moderator
Oct 31, 2009
5,263
1,579
Michigan
This definitely needs to be stickied for easy reference. It's neat to see the increase in performance from 384 to 528, but clearly no real overclocking is going on with the modded kernel. Thanks for the info (and SetCPU as well)!
 

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
Modifying the radio would probably take very significant reverse engineering. It's not something I'd like to even think about until we get the ability to de-brick. Best to tackle it from the kernel for now.
 

ralle.gade

Senior Member
Sep 13, 2009
216
1
I am editing the kernel for 32a sapphire and have modded the turbo settings. But still its only drawing very little benfit if it, it only gets a lil bit more responsive
 

jubeh

Senior Member
Mar 15, 2009
1,264
20
Modifying the radio would probably take very significant reverse engineering. It's not something I'd like to even think about until we get the ability to de-brick. Best to tackle it from the kernel for now.

Which radio?
AFAIK, the Dream has currently three radio firmwares available. Do you think that there's a remote possibility that people who reported a real increase might be running a different radio? Something we haven't considered?

Don't get me wrong. I thought placebo all throughout after reading the source (I haven't done any kernel programming, but I could see very little to indicate the changes were significant when I saw the source), but after people started reporting better performance at live wallpapers, and I know that those do lag severely where somebody would be able to tell whether they sped-up or not, then, do you think there's a possibility that a different radio FW maybe allowed a different speed to happen?

Currently, the 528,000,000 Hz speed is derived from the PLL2, but the Dream was created and released as a 384,000,000 Hz device.
Early on, with earlier radio firmwares, battery was used up faster than it was with subsequent firmwares. Do you think there's a chance that maybe part of the radio was running off of PLL2 and this was set to a higher frequency, thus explaining the faster battery drain, and then the fix was to slow down the radio?
Since we never really overclocked before FW 2.22.19.26I, we might have not noticed that using PLL2 for OCing might actually yield a different, faster clock than the current FW's PLL2's 1,056,000,000 Hz is yielding at PLL2/2?

Lastly, from a pure mathematical standpoint, division is inversely related to multiplication. Is there a way we can use "TCXO: 19.2MHz" multiplied by something to get higher clock speeds than it? If possible, and with the low speed, we might have more granular control of the clock.
 

coolbho3000

Retired Senior Recognized Developer
Dec 26, 2008
899
784
Since we never really overclocked before FW 2.22.19.26I, we might have not noticed that using PLL2 for OCing might actually yield a different, faster clock than the current FW's PLL2's 1,056,000,000 Hz is yielding at PLL2/2?

We can try benchmarking using both radios, but the kernel source has always shown "528000" as PLL2/2. This option has been available for a very long time in the kernel, even before cpufreq support was implemented. I kind of doubt that any earlier radios would run the PLLs at any different rate.

Lastly, from a pure mathematical standpoint, division is inversely related to multiplication. Is there a way we can use "TCXO: 19.2MHz" multiplied by something to get higher clock speeds than it? If possible, and with the low speed, we might have more granular control of the clock.
That's what the plan is for adjusting the PLL speeds, but there's apparently problems doing it from the ARM11. All the PLLs are TCXO*L, where L is a constant. It's not as simple as changing the frequency divisor to a fraction, because it's an unsigned int in the kernel, and according to the qualcomm docs it cannot be anything other than an integer.
 
Last edited: