CPU Overclocking to max 692 MHZ Big TNX to glemsom kernel

coolbho3000 said:

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).

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.

Click to expand...

Click to collapse

sschrupp said:

I think the key point of that quote is this:

"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."

That's stating that there isn't any overclocking happening.

Click to expand...

Click to collapse