Dear kernel developer glemsom,
First of all Really thanks for all the hard work in the kernel !!
There is a question what really isn't clear yet:
on the other (Official) android devices it isn't possible to beyond the real 528 MHZ they can only use the PLL1 to reach the 768 but with no success.
so the question is ho did you did this so that we can use custom frequency's?
That would be really nice to do with the other (Android)phones ..
I hope someone can clear this up.
Thanks.
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
very thorough and academic. pleasure to read. good study. only fault i could raise is that you shouldn't claim a difference is statistically insignificant, unless you have the statistical data to back it up (which should also be documented).
EDIT: just realised you were quoting someone else's work. guess the feedback doesn't completely apply then. thanks for bringing this info to us
Indeed this would not only be useful on android, I believe that No2chem(nuerom.com) got stuck with pll1 at 768 as the only option for overclocking. I believe he used android code to figure this out (if I remember one of his post correctly).
Then we could run our blackstones at 692 mhz in Windows mobile. I am currently running android on 692(did the tests in setcpu so it actually works)
Soooooooo after reading this I cant really see if there is anyway to overclock the Blackstone in Windows? - another few Mghz would be great!
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.
Okey maybe your right but if i do a long benchmark wit setcpu i get 17000 MS(milli second) with 528 MHZ and 9600+- Milli second with 692 MHZ.. so its really working.. thats the strange point.. so its working but HOW? with BogoMIPS?? and if i try to go beyond the 692 MHZ the phone Hangs so the frequents is really higher..
It would be nice if the kernel Developers can ensure this question
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
this topic can be Closed.
I now know how the overlock has been done.
ITs done by the kernel + Like this (19.2 x (0x25) = 710.4MHZ (0x25 HEX=37 Dec)
so how can we overclock the blackstone
i'm a noob so the most above is chinese for me
i use android and mini terrors ravage rom
mini terror works great but android a little bit slow
so more speed would be nice
Overclocking can be done this way:
1. open startup.txt (it should be located in the root of your sdcard)
2. find the line that starts: set cmdline
3. add acpuclock.oc_freq_khz=600000 to other parameters inside quotation marks
4. save and close the file
5. you are overclocking to almost 600MHz (31 * 19.2MHz = 595.2 to be exact because it must be an even multiplier)
NOTE THAT THIS MAY DAMAGE YOUR DEVICE. YOU'RE DOING IT AT YOUR OWN RISK!
BTW. My Blackstone won't go higher than 633.6MHz on recent kernels and IIRC it could go higher before
Related
Sent from my PC36100 using XDA App
http://forum.xda-developers.com/forumdisplay.php?f=652
I've had my phone overclocked 15% for months now...I pre-ordered and picked it up on June 4th (the day they were released to the public) and it's never been replaced. I rooted it right away using the engineering hboot method, and I immediately went to a rooted stock rom with a kernel that'd allow overclocking the very first time I saw one posted on this forum. I've never been able to run it at anything higher than 1152 mhz, but I've also never had any stability issues at 1152 mhz. I also allow it to go as low as 128 mhz all the time.
Since then I've played with various roms, and various kernels, but the first thing I've done when changing any rom or kernel, is always set the min and max CPU speeds again, and decide which governor to use. I've also always played with the undervolting strategies, from static to HAVS, and I've always been able to get away with the most agressive stuff posted without any stability issues.
Your mileage may vary, but thats been my experience with an overclocked Evo. I will admit I can barely notice the performance difference from 998 mhz to 1152 mhz, but I actually notice a battery life improvement...get it done faster so the CPU can go back to idling at a low frequency as soon as possible mentality I guess.
please watch what you say here. its not going to get you any help to curse and swear at other members. last warning
@MikeOD, which governor and what governor parameters have you found to work best for you?
I think the whole overclock boils down to what you do with your phone. If nothing overly cpu intensive, then there's likely to be little gain in the amount of saved time.
I actually have mine under clocked at 921 Mhz (came that way in the rom initially). UI was fluid enough and everything still seemed to work well/responsive. I get slightly better battery life too. Noticeable in the rate the batt % declines during active tasks (web browsing).
Goal of this little project is to dispel myths and hearsay and trying to assess the elusive performance of custom kernels for our beloved SGS I9000.
So far this has proven quite challenging as there is no single good benchmark on Android (yet):
a lot of people have been misled by ridiculous Quadrant scores: ridiculous because, with some small tweaks which do not affect real performance in any way, shape or form, it is possible to boost the Quadrant score by factor 3x.
You're free to believe that your SGS I9000 which scores 3000+ on Quadrant is faster than a SGS II, but then please leave this thread and move on.
some kernels may seem smooth with some games, and get high scores on some synthetic benchmark, yet the UI appears "laggy" and stutters a lot in comparison to other kernels which score lower on the same benchmark
some popular benchmarks give results with unacceptably low reproducibility, i.e. if you run them multiple times without changing a thing on your system, you get scores varying by 50% of more, in a completely random fashion
most popular benchmarks do not measure or take into account multitasking and CPU contention with other applications, yet on a typical usage one has background tasks such as the media scanner or synchronization which kick in often and unpredictably
So this will be mostly a work in progress, i'm testing several benchmarks and several kernels in multiple combinations, trying to analyze which benchmarks offer certain criteria which make them useful, namely:
Reproducibility of results: running the same tests multiple times, should result in a very small variance of the final score
Performance separation: benchmarks which are too "synthetic" and show only a dependency on clock speed are not useful to discriminate "fast" kernels from "slow" kernels
Performance representation: we all know when a kernel "looks" or "feels" fast or smooth. If a benchmarks shows you that a "laggy" kernel scores higher than a fast and responsive one, it's likely that the benchmark is not well designed
I'll work more on this thread explaining my (current) choice of tests and what they're good for.
But for now i'll just post a link to the summary table, and give a brief recommendation concerning popular ICS kernels; recommendation which i'll explain in the coming days.
Base ROM:
Slim ICS 2.8
(because is fast, smooth and has the least background stuff of all ICS ROMs which i tested)
Test Conditions:
Whenever possible, i tried to overclock the kernels to 1.2GHz which most / all phones should have no trouble achieving.
In case of Semaphore i had to use the bus / live overclock but it wasn't fully stable at 1.2GHz on my phone so i ran most of the tests at 1.14GHz.
Tested Kernels:
Stock Teamhacksung V17
Devil 1.1.6b BFS
Devil 1.1.6b CFS
Icy Glitch V14 b
Semaphore ICS 0.9.5b
Recommendation:
Devil 1.1.6b CFS, Icy Glitch V14b (with SmartassV2 and FIOPS), and Midnight ICS (with a tweaked Conservative) are trading blows for the fastest kernel.
At the time of testing, Midnight is slightly worse in terms of overclocking though, apparently due to different voltages, also it doesn't allow overclocking beyond 1.2GHz.
But what's interesting is that it achieves great performance while using a tweaked conservative governor.
Devil 1.1.6b BFS is good but obviously inferior to its CFS brother.
Semaphore has the lowest cache and memory latency in the multithreaded test, it also has impressive sd card read speed and in general appears super responsive, but it's a bit worse in 3D gaming and especially it lacks "true" overclocking, "live overclocking" changes the bus clock and is way more unstable, in fact on my phone i couldn't run it stable at 1.2GHz.
All kernels are significantly faster than the stock teamhacksung's kernel, so you have no excuses not to upgrade to one of the popular custom kernels!
ICS 4.0.4
Started testing Android ICS 4.0.4 kernels on Slim ICS 3.2.
All tested kernels are "huge mem" versions with 380+MB of available RAM, without breaking video playback or 720p recording.
Summary:
the stock kernel from Teamhacksung is now a very respectable performer, unless you plan to overclock probably you don't need to install one of the other kernels
Semaphore, Midnight and Devil are all very fast and smooth
Results table:
https://docs.google.com/spreadsheet/ccc?key=0AuBUEB4dGFSSdHIyN2VIeWU4QnhLOFpJejFPWDh5S1E
Res 1
One request for the kernel developers:
could you please post me what are your preferred / recommended settings in terms of Governor and I/O Scheduler?
Only one configuration per kernel please, as running these tests is rather time consuming.
Test Settings
So for anybody who wants to follow the same methodology as I used to test kernels, please pay attention that in some tests i didn't use stock settings, to try to improve the reproducibility of the results.
Before all test, i put the phone in flight mode, and disable all synch services.
Antutu: DB I/O and SD Write and Read have poor reproducibility. So i run these tests separately 5 times, and take the best scores.
RealPi: the number of iterations is increased by factor 10x i.e.: 100000 digits
MPAC: lots of customization here. Also be careful as it's not very stable and some settings will make it crash.
All tests: 8 threads (or 8 producer / consumer pairs)
CPU: 10000000 iterations, use case: integer (i'm considering to add logical too)
Memory: stock apart for nr of threads. Repeat the test 5 times and get best numbers
Cache: 40 iterations
Res 3
With this should be enough.
Judging from those results, CFS Devil looks really promising.
Semaphore live oc stability issues happen only on Slim ICS indeed. On ICSSGS I have perfect stability at 1.2 ghz. And performance is just great, paired with very good battery life.
GT-i9000 / ICSSGS 4.2 / Semaphore 0.9.0
A quick question: did you lock the max freq to eliminate the "governor" variable?
Because each kernel could have governor's tweaks that the other don't.
Based on what you posted here, the differences between Glitch and Devil is practically none.
I tested both and didn't feel any tangible difference, in the end, it comes down to the unique features of each kernel.
Overclocking bus vs adding an extra step aren't even slightly comparable. Maybe do tests not overclocked?
Also there is a new glitch build with 100% working bln.
Sent from my GT-I9000 using xda premium
+1 for tests without overclock. Majority of us, users do not overclock. Maybe a seperate test for overclocking could be nice , but comparisons should be done with stock speeds imho.
Thanks for the time and effort. We needed this.
Overclocking bus Vs adding an extra step isn't an apple to apple comparison, I agree.
However my goal was to use each kernel in the best possible way, and if some kernels have the possibility to use higher multipliers / extra frequency steps, that is an advantage for the user, compared to the kernels who only offer live overclock.
Don't get me wrong, i love Semaphore and i've been using it for a long time.
And i have no doubt that some users can get it stable with live overclock to 1.2GHz.
But that is the ceiling, while with other kernels even my phone can reach stable overclocks of 1.5GHz, and that is something to consider.
I chose as the basis for my tests an overclock of 1.2GHz because it's something which practically everybody can use, without massive battery drain, overheat or shortening the life of the device.
I'll try to add measurements at stock speeds for those who don't like to overclock.
cba1986 said:
A quick question: did you lock the max freq to eliminate the "governor" variable?
Because each kernel could have governor's tweaks that the other don't.
Click to expand...
Click to collapse
I didn't want to take the governor variable out.
Because, as you said, each kernel could use (and often does) governor tweaks which make the kernel "special" or different from the others, and that has to be taken into account in evaluating them.
Because nobody will use the phone locked at the maximum frequency.
So for me the governor and its tweaks is part of the user experience of a certain kernel, and a distinctive factor.
At the end, all kernels are coming from almost the same sources, so it's the little things which make the difference.
phzi said:
Also there is a new glitch build with 100% working bln.
Sent from my GT-I9000 using xda premium
Click to expand...
Click to collapse
That's great!
This test i run is not the "be all end all", it was just a recommendation at the time of writing.
Pipperox said:
Overclocking bus Vs adding an extra step isn't an apple to apple comparison, I agree.
However my goal was to use each kernel in the best possible way, and if some kernels have the possibility to use higher multipliers / extra frequency steps, that is an advantage for the user, compared to the kernels who only offer live overclock.
Click to expand...
Click to collapse
Agreed but, then again, benchmarks should be done at original CPU clock IMHO.
Otherwise, results are distorted.
HiKsFiles said:
Agreed but, then again, benchmarks should be done at original CPU clock IMHO.
Otherwise, results are distorted.
Click to expand...
Click to collapse
agreed. Especially since stock team hacksung seems to be clocked at 1GHz
what's the point of the comparison? Really?
As expected, there is no noticeable difference between all 1.2 GHz kernels.
It's not as if there was a real difference between them anyway.
zorxd said:
agreed. Especially since stock team hacksung seems to be clocked at 1GHz
what's the point of the comparison? Really?
As expected, there is no noticeable difference between all 1.2 GHz kernels.
It's not as if there was a real difference between them anyway.
Click to expand...
Click to collapse
That's not quite true.
If you look closer, you'll see that Devil CFS has quite a distinct advantage over all others in 3D tests.
The point of the comparison between stock hacksung @1.0GHz and the others, who can overclock, is to show what kind of benefit you get from switching to kernels which are overclock friendly.
Especially considering that you can't assume that a 20% clock speed increase will bring a 20% performance speedup across the board.
At last, i'd say that you may have "expected" that the kernels tested at 1.2 GHz don't have such a difference in performance.
But expectations have to be verified.
I tried to answer the questions:
On Devil's kernel, is BFS really better than CFS?
The "popular belief" is that BFS is faster than CFS.
According to my tests, CFS results faster instead.
Another question may be, what kernel gives you the best gaming performance.
If you pay attention to the An3D Bench XL, you'll see that Semaphore 0.9.5b, even overclocked a 1.2GHz, is significantly slower than Devil.
If i recall correctly Semaphore Author claimed that some kernel developers overclock GPU, and he didn't. Idk anything about it, but i recall something about it.
Is it possible to overclock only GPU, without overclocking CPU??
zipgenius said:
so you should benchmark them without setting anything. Average users don't overclock and don't change governor or scheduler: they flash the new kernel and stop.
Click to expand...
Click to collapse
I completely agree on benchmarking every kernel at the same frequency (stock 1Ghz max) but I think there are two different options for further benchmarking:
1) Benchmark kernels configured as similar as possible regarding CPU governor, IO scheduler, readahead -> comparable results for all kernels.
2) Benchmark kernels with default settings (only makes sense if all compared kernels are optimized for similar purpose like performance, does not make sense if a kernel does *not* focus on max. performance and uses e.g. Conservative CPU governor as default setting.
@Pipperox: Would it be possible to check my Mindnight-ICS dev version with your benchmark suite? I'd be really interested in the results as you use the same setup for all kernels (1.2Ghz would not be a problem, does not use LiveOC but old school 1/1.128/1.2Ghz OC).
Interesting thread... I never used devil's CFS version, always BFS. Will try CFS out now.
@Mialwe Where can we get your ics kernel?
mialwe said:
I completely agree on benchmarking every kernel at the same frequency (stock 1Ghz max) but I think there are two different options for further benchmarking:
1) Benchmark kernels configured as similar as possible regarding CPU governor, IO scheduler, readahead -> comparable results for all kernels.
2) Benchmark kernels with default settings (only makes sense if all compared kernels are optimized for similar purpose like performance, does not make sense if a kernel does *not* focus on max. performance and uses e.g. Conservative CPU governor as default setting.
@Pipperox: Would it be possible to check my Mindnight-ICS dev version with your benchmark suite? I'd be really interested in the results as you use the same setup for all kernels (1.2Ghz would not be a problem, does not use LiveOC but old school 1/1.128/1.2Ghz OC).
Click to expand...
Click to collapse
Sorry guys, i understand your logic but i do not fully agree with it.
I'm not comparing overclocked kernels with heavy tweaking of voltages and special settings with which they only work.
I did the "poor man"'s overclock, setting to 1.2GHz using NSTools, a setting where 95% of phones should have no problem working.
I think that if some kernels offer you this possibility while others do not, it is fair to use this "advantage" that they have over the other kernels.
Because a lot of users will have the possibility to do the same as i do, without esoteric knowledge and with just a couple of clicks in the menus.
That being said, "due to popular demand" i will also try to retest those kernels at 1.0GHz as soon as i get a bit of time.
BUT in my recommendations, i will also consider the overclocking capabilities.
@mialwe: sure, i'll give a run to your kernel as well!
mialwe said:
@Pipperox: Would it be possible to check my Mindnight-ICS dev version with your benchmark suite? I'd be really interested in the results as you use the same setup for all kernels (1.2Ghz would not be a problem, does not use LiveOC but old school 1/1.128/1.2Ghz OC).
Click to expand...
Click to collapse
Dude, sorry but i don't seem to find your ICS kernel anywhere.. can you provide a link?
Re: Post by user splus in Franco.kernel thread
Sorry to post in this forum, but I don't have the minimum post count yet to post in the development forums
I read a post today by splus which I found very interesting,
In r220 hispeed_freq parameter in governor control has been changed from 1200000 (was an old value from first version of Franco JB kernel) to 1228000. As a result CPU now spends most of its time at either at 384 or 1228 MHz, and much less time at higher frequencies.
For some reason if speed_freq value is set to a step lower than 1228000 then it will make CPU to use all higher frequencies in a more balanced way.
What I noticed is that for 1036 it needs to have slightly higher value of 1037000, because 1036000 will put the CPU only to 729 MHz. This is probably because the real 1036 MHz frequency is something like 1036.xx MHz, so it's best to set speed_freq value to a 1000 more than the desired frequency.
Hispeed_freq parameter is just an initial higher speed frequency that CPU will jump to when there's some CPU load. And if the CPU load is still high after the CPU goes into this frequency (in other words if this frequency is not enough to finish the job) then interactive governor will put the CPU in even higher frequencies.
On stock JB kernel max frequency is 1200 MHz, and hispeed_freq is 700000.
When speed_freq is set to 1228000 it will use mostly 384 and 1228 MHz frequencies.
Set speed_freq to 1037000 (or previous 1200000) and more higher frequencies will be used.
There's certainly many possibilities to play with min and max CPU values, together with speed_freq to come to the best values. And probably for each max CPU frequency different speed_freq value would work best...
Click to expand...
Click to collapse
but I wanted to learn more so I did a lot of Googling about the parameters of the interactive governor. Unfortunately, I kept finding the same few beginners' guides to the different governors available, explaining and comparing their capabilities. There was no advanced explanation of the parameters or their possible valid values.
I found this post by RootzWiki user abqnm, which shed a little more light on the hispeed_freq parameter, and input_boost also. From what I've read on various sites, the input_boost seems to be a binary parameter, so setting it to 1 should jump the CPU up to the frequency specified in hispeed_freq immediately upon detecting a screen touch event. This would make your GNex feel a bit more responsive, without having to wait for the CPU to hit load, but it could negatively affect battery life. In my case, running 729/1612 with hispeed_freq set down at 1036MHz (1037000 in governor control), it's not that big a jump and opening a couple of apps would likely push my speed up beyond it soon anyway, so the battery hit would probably not be much.
As splus said:
After lot of fiddling I found it works best when hispeed_freq is set to 1037000 (not 1036000, it looks like that frequency is actually closer to 1037 MHz so 1036000 doesn't "reach" it).
Click to expand...
Click to collapse
so using 1036000 in governor control would correspond to the next step down, 729MHz. I know it's easy enough to stick on an extra 1000 for safety, to ensure we hit the right steps, but I'd be curious to know the exact kHz values we could be using.
I'm off to start experimenting with undervolting these new CPU freqs, and my 512GPU Core to reduce my temps a bit.
In case anyone asks, I'm on stock JRO03C w/Franco r220 512GPU.
Very good post! Welcome to XDA! :good:
I'll link to your post on the franco thread just so it gets a couple views from people there.
Edit: I see that you've actually been here awhile! Go help a few more people so you can contribute in the Dev forum.
Yup, that's me... total lurker! I usually defer to the wisdom of the devs and seasoned members, and 99% of the time if I've had a problem/question re my Nexus it's already been posted and there are whole conversations for me to read and digest. I hate the idea of clogging up a thread with a "me too" or "thanks" post, so generally if I don't have something useful to contribute I keep quiet and hang in the shadows. I only come out to feed.
So basically, I'm a knowledge vampire.
That's enough OT... Franco stuff!
I've previously read droidphile's governors thread to which splus linked in their reply to your repost in Franco.kernel. In post #2, containing the governor tweaks (which I found very useful) even droidphile seems to have the wrong idea about the "hispeed_freq" parameter, stating:
(Default value is scaling max freq)
Click to expand...
Click to collapse
The same section also omits any mention of the "input_boost" parameter.
My undervolting is going well. Inspired by the voltages on rogersnm's signature, I'm currently running these:
Code:
1612 - 800 mV
1536 - 750 mV
1420 - 750 mV
1305 - 750 mV
1228 - 725 mV
1036 - 725 mV
729 - 700 mV
384 - 700mV
CORE -
512/384 - 900 mV
307 - 900 mV
153 - 825 mV
IVA -
266 - 600 mV
133 - 600 mV
I added an extra 100mV to the seemingly rock bottom CPU voltages for safety, but I'll try to reduce them gradually. I've been stable for over 40 hours so far on this setup. With r220, Franco really seems to have nailed it!
BTW, thanks for reposting in the Franco.kernel thread :highfive:
Fantastic. Keep us updated on your progress with voltages, seems like you're doing a great job!
Also, happy to help!
nemotheblue said:
Code:
1612 - 800 mV
1536 - 750 mV
1420 - 750 mV
1305 - 750 mV
1228 - 725 mV
1036 - 725 mV
729 - 700 mV
384 - 700mV
CORE -
512/384 - 900 mV
307 - 900 mV
153 - 825 mV
IVA -
266 - 600 mV
133 - 600 mV
I added an extra 100mV to the seemingly rock bottom CPU voltages for safety, but I'll try to reduce them gradually. I've been stable for over 40 hours so far on this setup. With r220, Franco really seems to have nailed it!
BTW, thanks for reposting in the Franco.kernel thread :highfive:
Click to expand...
Click to collapse
I'm trying these too. So far so good!
Hi nemotheblue. Good post and findings!
I'm just looking at those voltage values you wrote - are you sure you turned off the SR?
If you haven't don't turn it off with those voltages because you'll get an instant reboot, they seem super low.
Rogersnm wrote and fiddled a lot with voltages, some very good posts.
Better go back to stock voltages, turn off the SR, and then go little by little down with frequencies. When adjusting each frequency best is to set that particular frequency as min (or max if it is higher) frequency so the CPU actually uses it.
And when you get a reboot then just use 25mV higher than the one with reboot.
I'd suggest to have fsync turned on when you fiddle with voltages because that will lessen the possibility of loss of data when phone reboots.
Another thing to have in mind is that even some combinations of frequencies do not work together. Some frequency might work OK with certain voltage with certain max/min frequencies but might not with other min/max frequencies. It looks like the actual change from one frequency to another (and depends from which to which) can determine a lot if a voltage is stable or not.
Also, it apparently very much depends on a ROM you use - different ROMs will probably need readjustment of voltage table.
Undervolting actually won't help much with battery life, smart reflex does a very good job already. It would help most if you game a lot or use your phone heavily, so then when higher frequencies are used the phone would get less hot and use slightly less power.
Otherwise, and especially if you change ROMs, I'd say it isn't worth the trouble.
nemotheblue said:
..................................
I've previously read droidphile's governors thread to which splus linked in their reply to your repost in Franco.kernel. In post #2, containing the governor tweaks (which I found very useful) even droidphile seems to have the wrong idea about the "hispeed_freq" parameter, stating:
..............................
Click to expand...
Click to collapse
Since there's lot of info to cover, mistakes can happen. I'll correct it if something is wrong.
Anyhow, if you check the interactive governor code,
if (!hispeed_freq)
hispeed_freq = policy->max;
This means if kernel default for the value of hispeed_freq=0, then it's assigned to policy_max aka scaling_max.
hispeed_freq is kinda like max_load_freq for ondemand.
Btw, input_boost is not available for interactive governor 'designed' for i9100 GS2 with Exynos chip. I don't know about Gnexus' Omap. Since i take one of the GS2 kernel as reference, governors params are kinda specific to i9100 and exynos architecture.
splus said:
Hi nemotheblue. Good post and findings!
I'm just looking at those voltage values you wrote - are you sure you turned off the SR?
...
I'd suggest to have fsync turned on when you fiddle with voltages because that will lessen the possibility of loss of data when phone reboots.
...
Undervolting actually won't help much with battery life, smart reflex does a very good job already. It would help most if you game a lot or use your phone heavily, so then when higher frequencies are used the phone would get less hot and use slightly less power.
...
Click to expand...
Click to collapse
@splus Wow, thanks for joining in on my little thread! Rest assured, before I started my tinkering I turned SR off and fsync on. I've read all 2306 pages of the Franco.kernel thread and avidly followed several conversations within it. I don't mind being a bit adventurous and trying out tweaks and mods; I just prefer to let other, more educated people try it first! I'm a measure twice, cut once kinda guy.
I followed rogersnm's undervolting saga in the Franco thread up to a couple of weeks ago, and recently caught up with his linaro thread, but I was as amazed as you seem to be at the tiny numbers he's currently reporting.
That being said, the voltages I reported were totally stable for me the last 3 days, until tonight. Tonight, I went to a double bill of Batman Begins and The Dark Knight - 5 hours in a huge, sold out cinema with easily 1,000 people. By the second movie, the room temperature was in the high 30s, if not 40C. I got an email, had a read, tapped back to inbox and BAM! The screen froze for about 3 seconds, then rebooted. The crazy thing is, I tried an hour later to reapply the undervolt and it froze straight away. I'm back on SR for a while, but I might try again tomorrow.
My original intention with the undervolting was just to drop the CORE, because I'm getting great performance from the 512GPU, but I notice the area under the camera on the back of the phone can get pretty hot if I'm playing games or watching a video for >30mins. Granted, I don't do that too often, but I figured it'd be nice to eliminate the extra heat. Once I saw the power saving calculations in rogersnm's chart, I was convinced to go the whole hog. The jury's out...
droidphile said:
Since there's lot of info to cover, mistakes can happen. I'll correct it if something is wrong.
Anyhow, if you check the interactive governor code,
if (!hispeed_freq)
hispeed_freq = policy->max;
This means if kernel default for the value of hispeed_freq=0, then it's assigned to policy_max aka scaling_max.
hispeed_freq is kinda like max_load_freq for ondemand.
Btw, input_boost is not available for interactive governor 'designed' for i9100 GS2 with Exynos chip. I don't know about Gnexus' Omap. Since i take one of the GS2 kernel as reference, governors params are kinda specific to i9100 and exynos architecture.
Click to expand...
Click to collapse
@droidphile Thanks for taking the time to reply. I didn't mean to sound like I was attacking your guide; I'd just read conflicting information from multiple other sources and played the numbers. I was labouring under the false assumption that all interactive governors are created equal. Is there some kind of official/original reference/guide/man page for the governors and their parameters, or are you devs left to interpret the code for yourselves?
I must admit, I'm more confused than ever now. I just can't reconcile your explanation with splus' claim that hispeed_freq=1037000 is the sweet spot for getting interactive to use the intermediate freqs up to a max well above 1036MHz???
nemotheblue said:
@splus Wow, thanks for joining in on my little thread! Rest assured, before I started my tinkering I turned SR off and fsync on. I've read all 2306 pages of the Franco.kernel thread and avidly followed several conversations within it. I don't mind being a bit adventurous and trying out tweaks and mods; I just prefer to let other, more educated people try it first! I'm a measure twice, cut once kinda guy.
I followed rogersnm's undervolting saga in the Franco thread up to a couple of weeks ago, and recently caught up with his linaro thread, but I was as amazed as you seem to be at the tiny numbers he's currently reporting.
That being said, the voltages I reported were totally stable for me the last 3 days, until tonight. Tonight, I went to a double bill of Batman Begins and The Dark Knight - 5 hours in a huge, sold out cinema with easily 1,000 people. By the second movie, the room temperature was in the high 30s, if not 40C. I got an email, had a read, tapped back to inbox and BAM! The screen froze for about 3 seconds, then rebooted. The crazy thing is, I tried an hour later to reapply the undervolt and it froze straight away. I'm back on SR for a while, but I might try again tomorrow.
My original intention with the undervolting was just to drop the CORE, because I'm getting great performance from the 512GPU, but I notice the area under the camera on the back of the phone can get pretty hot if I'm playing games or watching a video for >30mins. Granted, I don't do that too often, but I figured it'd be nice to eliminate the extra heat. Once I saw the power saving calculations in rogersnm's chart, I was convinced to go the whole hog. The jury's out...
@droidphile Thanks for taking the time to reply. I didn't mean to sound like I was attacking your guide; I'd just read conflicting information from multiple other sources and played the numbers. I was labouring under the false assumption that all interactive governors are created equal. Is there some kind of official/original reference/guide/man page for the governors and their parameters, or are you devs left to interpret the code for yourselves?
I must admit, I'm more confused than ever now. I just can't reconcile your explanation with splus' claim that hispeed_freq=1037000 is the sweet spot for getting interactive to use the intermediate freqs up to a max well above 1036MHz???
Click to expand...
Click to collapse
Yeah, if you do some gaming and more intensive stuff then it might be worth to find some good voltage values.
Still, those voltages seem pretty far from what hardware would be capable of running so that makes me think the SR check box wasn't really displaying its actual state somehow.
If you were using Franco's app did you check the last tab to see if mV values at certain frequencies were the same as in your table? If yes then I'm just amazed you were able to run it that way...
Anyway, good luck with further undervolting, please post your stable voltages when you find them...
If you have higher OC CPU frequency as max value in interactive (I'm talking about GNex, every chipset behaves differently) then it looks to me that if you set hispeed_freq to 1228000 the CPU would often just stay at that frequency, as if the system decides that it's enough to finish the job. But if you set it to 1037000 then it often determines it is not enough and scales the CPU to higher frequencies, and then you get the CPU to actually use higher frequencies as well.
Other direction would be to set hispeed_freq to even higher frequencies and that'll definitely make it more responsive but at a battery life cost.
The most responsive system would be that CPU goes to max whenever there's something happening. Google actually said at their IO that they tuned JB to go to max frequency at any touch but if you use the stock kernel and check CPU Spy charts you'll see that CPU goes initially only to 700 MHz.
There are other parameters, but it's all about finding a sweet spot for performance and battery life...
Needless to say, tuning all those governor parameters is greatly dependent on available frequencies, programmatically implemented governors and its parameters (which can be changed, a kernel developer can design and implement his own governor and its parameters) and especially chipsets and the way they behave. Every device is very different...
I think we would have better performance if there would be less frequencies in a kernel than currently in Franco's, but if the CPU is really efficient at scaling frequencies up and down through many steps all the time then maybe not.
Either case life goes on and I'm looking forward to see that new Batman myself in couple of days!
Fine folk of XDA,
Apologies for my long absence! I wasn't abandoning the thread; I got a call to work on a short film and had an insane 10 days of 13-16 hour working days and my brain was just too tired in the evenings to keep up with testing and tweaking. Plus, I needed my phone 24/7 stable to handle the continuous flow of calls, texts and emails from the production office.
So, I reverted to SR and dropped my max freq to 1228 and had no problems.
Catching up on the Franco thread tonight, I read a post by daggerxXxsin saying
I am running 600mv on 384-729 and 675mv on 1036-1228. Only works when I'm on 512gpu though. No random reboots or nothin'. Plays games like a champ and never heats up (temp never goes higher than 45°)
Click to expand...
Click to collapse
I'm currently trying these out on 729-1228 with SR off and fsync on, along with the following:
Code:
CORE -
512/384 - 900 mV
307 - 900 mV
153 - 825 mV
I'm gonna leave IVA alone on SR. I never really noticed any difference undervolting it before, and I figure if I'm pushing my MPU voltages so low, I'm just begging for crashes so it's best not to mess with anything that would affect I/O.
I'm currently running r225 512GPU, and I had some wifi issues where the indicator would frequently switch from blue to grey and lose the connection. However, having read some frequent posts in the Franco thread, I've switched from CWM to TWRP, wiped caches and reflashed Franco so I'll wait and see if the problem resurfaces.
BAH! Screw it, I just refreshed the Franco thread and r230 is out. Gonna flash and see how I get on...
Hi again nemo, just stumbled on this thread again
Wondering what posts indicate that CWM vs. TWRP recoveries would make a difference for the booted OS's Wifi/Google Services connectivity?
As I understand it JB in general just has a bit of a Wifi problem vs. ICS and even with ICS the Galaxy Nexus does vs. any other phone. I'm currently having acceptable Wifi using franco 241 (which has a new IO scheduler which makes things feel extremely snappy).
I'm pretty sure all I based that decision on was this discussion in the Franco.kernel thread. In retrospect, kinda half-baked but I must say I'm impressed with this recovery anyway!
I'm still following the thread religiously, rocking M5 at the moment though I'll likely jump on the first 512GPU nightly that comes out. I spent hours yesterday reading the MiNCO and MiNCO+ threads, very carefully backed up, then flashed v4 and immediately ran into this major roadblock and ended up reverting. Further study is required...
A few things come to mind with that storage problem:
1) Maybe that the sdcard bin (as is also in franco's cwm zips) is installed and messing things up weirdly. You'll need to push the stock one back (first post of franco.Kernel thread iirc).
2) A recent ROM Manager bug where .nomedia files were getting placed in the /sdcard/ top level folder, so you might want to investigate that with adb shell (though this would be weird considering you say you're using TWRP and ROM Manager is CWM).
3) Go to Apps > All > MediaStorage, Force Stop and clear data+cache. Reboot to have MediaScanner rebuild the MediaStore.
Edit: Just saw your post in the linked thread... looks like you tried 2+3... so try 1?
osm0sis said:
...1) Maybe that the sdcard bin (as is also in franco's cwm zips) is installed and messing things up weirdly. You'll need to push the stock one back (first post of franco.Kernel thread iirc)...
Click to expand...
Click to collapse
Very clever! Way to think outside the box, ossie :highfive:
I should have time to try again tonight, so I'll let you know how it plays out. While I'm at it, I'm excited to try out DarkJelly's inverted gapps, but I'll make sure to tackle the storage problem before flashing any apps/mods
So I couldn't wait!
I was unable to shake the feeling I might have just had a bad download of MiNCO, so I grabbed a fresh copy before I began. Flashed the ROM, Gallery worked fine. Flashed a navbar/battery icon mod, Gallery still ok. Gapps, no problem. Inverted apps, smooth sailing!
I now have a fully functional, customised ROM and no storage problem whatsoever. I must've just borked the first MiNCO download...
All's well that ends well
And I successfully tricked you into making your 10th post, so my work here is done! :laugh:
Now come join us in the main thread :good:
osm0sis said:
And I successfully tricked you into making your 10th post, so my work here is done! :laugh:
Now come join us in the main thread :good:
Click to expand...
Click to collapse
Nice one! :highfive:
Hi there. I have a strange "issue" with my phone. Substantially, it looks like I have a chip capable of EXTREME undervolting. For example, gpu running @ 160 mhz and ONLY 700 mV. 533 mhz is @ 925 mV. It's pretty exaggerated in my opinion. I stress tested the gpu with all benchmarks and games that came in my mind at all steps. Same performance but huge undervolting. I am using Thunder Lite v3 and Neak kernel 2.02. I am currently, after 3 hours of messing with the gpu, dedicating myself to the cpu. I am now typing this with four cores active @ 1.6 ghz and, attention, 1000 mV. And there's still room for more...
It's too much in my opinion, so this may be a stupid question. Is this normal? Are there any powerful stress tests I may use? I am using multiple runs of Antutu at the moment. Is there a way I can verify the voltages I am applying are actually corresponding to what the cpu gets? It's too much in my opinion. I could have some huge luck, but I doubt.
Which kernel is best for performance?(for Whyred)
1. Black box
2.no name
And many out there???
Suggestions please.
Thanks in advance.
Deep.cdy said:
Which kernel is best for performance?(for Whyred)
1. Black box
2.no name
And many out there???
Suggestions please.
Thanks in advance.
Click to expand...
Click to collapse
You should try them and find out the most suitable for you, use them for 1-2 days, you'll see the difference.... personally, I'm using NoName kernel with RR
NoName for Lineage based.
Deep.cdy said:
Which kernel is best for performance?(for Whyred)
1. Black box
2.no name
And many out there???
Suggestions please.
Thanks in advance.
Click to expand...
Click to collapse
i think currently is noname.
we hope a bunch of recognised developers in the near future as franco as many others.
Kirks, for battery...
Dude unlocked the lower cpu freqs...
m666p said:
Kirks, for battery...
Dude unlocked the lower cpu freqs...
Click to expand...
Click to collapse
It operates on lower Volts using this unlocked freqs?
peter-k said:
It operates on lower Volts using this unlocked freqs?
Click to expand...
Click to collapse
God knows, but what I do know is that it should produce less heat at the very least and it performs pretty gud on powersave governor. The gpu on the other hand is garbage at min freq (160mhz), even the launcher lags....
peter-k said:
NoName for Lineage based.
Click to expand...
Click to collapse
But after flashing no name 1.3 the WiFi doesn't work for me on rr 12th June
Deep.cdy said:
But after flashing no name 1.3 the WiFi doesn't work for me on rr 12th June
Click to expand...
Click to collapse
Mine was fine but now I'm on Aosip.
i think for now the best is to use a stock kernel, be careful with the charging limits.
peter-k said:
It operates on lower Volts using this unlocked freqs?
Click to expand...
Click to collapse
m666p said:
God knows, but what I do know is that it should produce less heat at the very least and it performs pretty gud on powersave governor. The gpu on the other hand is garbage at min freq (160mhz), even the launcher lags....
Click to expand...
Click to collapse
Of course it operates at lower voltage as it's a lower frequency and requires less power draw. Lower voltages should mean lower heat, however you don't magically get that lower freqs to operate, you need to tweak the interactive governor to make use of them all efficiently. So far I'm on Kirks kernel and AOSiP and it's a quite good combo.
The lag is not caused by low GPU freqs, it's because of low CPU freqs for that particular load, so governor tweaking is needed.
Cirra92 said:
Of course it operates at lower voltage as it's a lower frequency and requires less power draw. Lower voltages should mean lower heat, however you don't magically get that lower freqs to operate, you need to tweak the interactive governor to make use of them all efficiently. So far I'm on Kirks kernel and AOSiP and it's a quite good combo.
The lag is not caused by low GPU freqs, it's because of low CPU freqs for that particular load, so governor tweaking is needed.
Click to expand...
Click to collapse
Lol, I tested what you said out. Because you said it with such confidence...
I changed the cpu governor to performance and set the gpu to 160mhz max...
That made the experience a bit better but it would still lag a lot in recents and app launcher scrolling...
I've attached a screen shot to prove it too...
Another thing, just because the clock is lower does not mean that the voltage is lower as well, many devices that ive owned over the years have had the same voltage's for lower clocks( moto g2, Sony xperia z1)
And lastly, you should "magically" get those lower frequencies(if they are truly unlocked) since governors will always operate within the min/max frequencies that are set by the user or by default(unless it reverts parameters back to stock, like our device does on interactive)...
Forgot screenshot....
m666p said:
Lol, I tested what you said out. Because you said it with such confidence...
I changed the cpu governor to performance and set the gpu to 160mhz max...
That made the experience a bit better but it would still lag a lot in recents and app launcher scrolling...
I've attached a screen shot to prove it too...
Another thing, just because the clock is lower does not mean that the voltage is lower as well, many devices that ive owned over the years have had the same voltage's for lower clocks( moto g2, Sony xperia z1)
And lastly, you should "magically" get those lower frequencies(if they are truly unlocked) since governors will always operate within the min/max frequencies that are set by the user or by default(unless it reverts parameters back to stock, like our device does on interactive)...
Click to expand...
Click to collapse
First of all, we are talking here about difference in voltage between stock minimum freq for big cluster, which is 1.1ghz and actual possible minimum which is 300mhz, and there is a difference in voltage, that was the point. The devices I owned, S5 and Z3compact had more CPU steps, therefore the difference between some of the steps was really small or there wasn't any, but the CPU scaling made a jump to the freq with bigger difference (higher or lower, that was the stock behavior so some freqs weren't used). Here it might use all of the freq steps as there are less of them and the difference in voltage is significant enough, which might be the case, I said that because of my experience with previous devices. But you've missed the point anyway, I have said that even if unlocked, some freqs won't be used just because they are there if the governor parameters aren't set properly (or will be barely used). That was my point, I said that as a general note, so users won't jump the gun and blame devs for whatever.
And another one, regarding your test and lag with GPU, now I'm confused why would you set your max at 160mhz? I know it was for testing purposes in this case, but you did complain about it in original post and I said it won't lag because the max would still be set to 430mhz in which case the GPU freq scaling would do the job which it does very good so far. It would lag of course if you set max GPU freq to 160, but that's not what would you do for daily usage, right? Sorry if I misunderstood something.
Cirra92 said:
First of all, we are talking here about difference in voltage between stock minimum freq for big cluster, which is 1.1ghz and actual possible minimum which is 300mhz, and there is a difference in voltage, that was the point. The devices I owned, S5 and Z3compact had more CPU steps, therefore the difference between some of the steps was really small or there wasn't any, but the CPU scaling made a jump to the freq with bigger difference (higher or lower, that was the stock behavior so some freqs weren't used). Here it might use all of the freq steps as there are less of them and the difference in voltage is significant enough, which might be the case, I said that because of my experience with previous devices. But you've missed the point anyway, I have said that even if unlocked, some freqs won't be used just because they are there if the governor parameters aren't set properly (or will be barely used). That was my point, I said that as a general note, so users won't jump the gun and blame devs for whatever.
And another one, regarding your test and lag with GPU, now I'm confused why would you set your max at 160mhz? I know it was for testing purposes in this case, but you did complain about it in original post and I said it won't lag because the max would still be set to 430mhz in which case the GPU freq scaling would do the job which it does very good so far. It would lag of course if you set max GPU freq to 160, but that's not what would you do for daily usage, right? Sorry if I misunderstood something.
Click to expand...
Click to collapse
I kinda get what you mean, but the min freqs should kick in by default. They don't though on kirks, you need to change the governor to something like alucard or zzmove once before it actually starts clocking down to 300mhz...
On a side I would just disable the big. Cluster if I could, I don't really need that much cpu performance...
I was trying to find the min gpu freq that would be usable and I was disappointed, cuz my Sony z1 had a smooth ui experience with the gpu clocked at 200mhz max and that thing had a sd800...
Btw, I do all this to get better battery life...
I found out something else, I can't use power save governor any more because it can't handle audio processing(ainur, v4a) when the screen is off...
Just like my old z1, Lol...
Makes me think that the performance is really identical to the snapdragon 800...
I wonder how pissed I would be if a I got the redmi 5 plus, the 625 would have been even worse...
m666p said:
I kinda get what you mean, but the min freqs should kick in by default. They don't though on kirks, you need to change the governor to something like alucard or zzmove once before it actually starts clocking down to 300mhz...
On a side I would just disable the big. Cluster if I could, I don't really need that much cpu performance...
I was trying to find the min gpu freq that would be usable and I was disappointed, cuz my Sony z1 had a smooth ui experience with the gpu clocked at 200mhz max and that thing had a sd800...
Btw, I do all this to get better battery life...
Click to expand...
Click to collapse
m666p said:
I found out something else, I can't use power save governor any more because it can't handle audio processing(ainur, v4a) when the screen is off...
Just like my old z1, Lol...
Makes me think that the performance is really identical to the snapdragon 800...
I wonder how pissed I would be if a I got the redmi 5 plus, the 625 would have been even worse...
Click to expand...
Click to collapse
Yeah I agree, it should, but how much it stays on minimum freq is dependent on couple of governor parameters (talking about interactive). On mine though it does stay on 300mhz when idling, on stock Kirks settings. Big cluster can be disabled through new hotplug solution, like Intelliplug, which I used on my old devices, and it performed great, 1 core was active when screen was off, screen on and light usage required only 2 cores, while all 4 were active under heavy load. Here however there is only Qualcomm's hotplug solution, until that changes, no luck. Regarding GPU freq, I don't think any device would work smoothly under 200mhz, you can set 266mhz here, it will be smooth, I've tested today, on my old SD801 it performed at 233mhz IIRC.
I've seen that, V4A requires higher freq than 300mhz, or even 422mhz which SD801 had, it's more about the freq rather than the chipset, as I've read on multiple threads that even the devices with SD820 were struggling a lot when processing audio at 300mhz when the screen was off. Don't worry, it's a general issue. There is also the optimization of the rom and audio mods as well, background tasks, kernel, it all goes into the mix.
This is actually a very good chipset, it's technically SD660 just with lower clocks on both CPU and GPU.
EDIT: I forgot, this is my usage on AOSiP + Kirks, stock interactive tunables, min freq 300mhz (big/little), GPU initial/min freq 160mhz, max 430mhz. Using microG instead off GApps, I have used FB, Instagram, Messenger app for 1,5h each, Viber was couple of hours, Chrome some 30mins, Panini sticker album 30+ minutes, 30 minutes of 2G calls. Network mode was LTE, though I was on wifi on whole charge.
Started measuring from 92%.
Thanks bro, that explains a lot...