Related
I just tried chainging my cpu speed using some programs I found
first of all I tried xcpuscalar, but the whole machine freezed and I had to do a soft reset
next I tried a program I found on this site called overclock, it was not designed for this device but I wanted to try it and hoped that it would work, but unfortunately it gave the mesage when I tried using "unable to execute"
and now I am using phm but this also has some problems as an example the whole machine freezes with a bus of more than 130, so this limits the speed to 520 mhz. this happens while using speed configuration on that item
Is there someone else who tried o/c or u/c on his magician(I have an t-mobile branded version)? and if so with which program, and what are you're experiences? How far were you able to go?
I find it hard to believe the max for the magician is at 520 mhz so I hope there is someone who knows more about this
Did u try pocket hackmaster yet......??? It has a good reputation.
http://www.pocketgear.com/software_detail.asp?id=7258
yes phm is pocket hack master, but when I try a bus higher then 130 the program hangs, and I have to do a soft reset, the maximum speed I can get this way is at 520 mhz, and I was hoping to push it some bit further
edit: I had the hack master 3.05 version as a trial because I first wanted to see if the program worked, but now after only 2 days the trial has expired, so maybe there is someone else who has a registered version and willing to also give it a shot
i also tried PHM 3.05.001 and noticed the 130MHz bus limit..
however if you add a manual speed, u can increase the clockspeed multiplier and take it way higher than 530MHz - i had it running at 845MHz!!! but surely that cant be good for the phone? although it passed all the stress tests and so on....
also... shortly after i did that the phone crashed and i was forced to hard reset!!! my punishment for overclocking too much
thanks for the info, the only problem now remaining is that the trial has expired and I first want to test this before buying it
ah well, too bad, I only find it very strange that when you have a trial for 10 days it stops working after only one day :?
Dear all
Try to Put in 111 111 111 111 111 111 on the serial no and see.
enjoy
nice the code works thx's
Do Yyou erally notice that higher speed on your compact? Because otherwise i would overclock mine also to bus 130 mhz
What are the advantages ?
Don't trust the clock value reported by PHM! Use third party program like Betaplayer and U will found the value report by PHM is not correct
I can set PHM to report a 926mzh!!! and un the tests OK. But betaplayer reports only 494 (and it can be proved by the similar benchmark of PHM itself or from Betaplayer)
Magician probably use some relatively poor quality ram or components that post a 130mzh limit on the bus and there is no way to use any software to overcome physical limit. For stability, I will only set it to 124mzh.
HOW DO YOU SET UP A MANUAL SPEED FOR BENCHMARKING THE CPU SPEED?!?!?!?
I just wondered if the mini ( or ppc architecture in general ) is layouted for scaling cpu and bus frequencies. all you guys just do it, and I think that at least downscaling during idle time like centrino notebooks do is a great feature to save batterie time, but is the basic hardware architecture made to cope with the chaning tensions / currents ?
If the answer would be a yes, then why the hack this feature is not implemented in windows ce ?
So I tend to say no it isnt... maybe somebody could give evidence
thx in advance
in response to the question by iCue,
yes, the hardware is made to cope with the changing clock multiplier/clock frequencies...
the title of the CPU itself, "scalar" means that it is capable of scaling the speeds up and down to conserve battery life etc...
unfortuantely, microsoft being micrsoft, did not implement this (hence programs like pocket hack master being needed)
HighPingBastard said:
in response to the question by iCue,
yes, the hardware is made to cope with the changing clock multiplier/clock frequencies...
the title of the CPU itself, "scalar" means that it is capable of scaling the speeds up and down to conserve battery life etc...
unfortuantely, microsoft being micrsoft, did not implement this (hence programs like pocket hack master being needed)
Click to expand...
Click to collapse
When i use XCPUscaler, then i notice that my magician works not so good as else. Under 10 % it scales to 208 Mhz in stead of 416 to save power but when i do something big like view foto's then xcpuscaler sometimes doesn't speed up my magician. Nobody noticed this on his magician?
That's the reason why i stopped using it !
Thanks
HighPingBastard for this precise answer
@ThEScReW : Naturally it is a problem that if you use 100% of 200 Mhz it is hard for phm to gain enough to upscale the cpu...
so well... no I didnt realise this problem yet ;D
Hello to all of you!
I've honestly searched the web and particularly this forum to find questions related to my current problem - finding the best settings for my phone's CPU that will fully suit me.. But there are also answers I've failed finding myself.
So, I have an Android mobile phone, Mobistel Cynus T1, which is MTK6577-powered. And I want to tweak its CPU controlling (assume that I already understand what all of that 'governors' and 'i/o shedules' stand for) with, let me say, the app SetCPU. The phone has been rooted already.
So, I installed this app and chose Continue Recommended in a pop-up window when launching for the first time, and the next frequencies and governors and shedules were defined for my phone:
Freqs: 250 500 667 750 834 1001 MHz
Governors: ondemand, userspace, powersave, hybrid, performance
i/o shedulers: noop, cfq, deadline
Here are the questions (sorry if the intro was useless or unnecessary, but I thought it is needed):
What is that 'hybrid' governor? I really couldn't find even a mention of it.
That upper list of freqs, are these freqs show the full range od freqs available for MTK6577, or not? If not, what freqs could be added?
What freq is the most energy efficient for MTK6577? I am asking this because I've read in some thread in xda-forum that the lowest freq doesn't mean the lowest battery consumption.
The 'powersave' governor, does it automatically finds the most most energy efficient freq or just sets the lowest? (referring to 3rd question)
If i set 'cfq' for all the profiles and 'noop' for screen-off profile, is it okay and wouldn't such a combination of shedulers harm my device?
Now come questions that as I think are related to the SetCPU app rather than to tweaking CPU in general:
My current working profile is 'CPU 250-834, hybrid, cfq'. Why than I often see that the proc increases its freq to 1000MHZ? There is no conflicting app and the SetCPU was allowed via a root-allowing app.
For the 'hybrid' governor, there are some settings which explanations I couldn't find:
down differencial
ignore nice load
io is busy
load critical grade
load high grade
load warning grade
load medium grade
load light grade
load critical
load high
load warning
load medium
load light
load up bound
load down avg times
Thank you for reading all this and double thanks for helping
Nobody knows?.. Or I am asking the fool questions?)
Отправлено с моего Cynus T1 через Tapatalk
Wen u install setcpu for mtk.. ... der is a instruction wen u r increasing d frequency u also need to change the
Voltage input. And the wen u increase the voltage input battery discharges fast.. nd u hve to chek d best settings by changing dem nd den chking whether d fone is working smoothly if not chnge settings to default.. . Like wise u can differnt settings n... nd Dnt click on apply on reboot while chking it
Sent from my Spice MI-350n using XDA
blueneel said:
Wen u install setcpu for mtk.. ... der is a instruction wen u r increasing d frequency u also need to change the
Voltage input. And the wen u increase the voltage input battery discharges fast.. nd u hve to chek d best settings by changing dem nd den chking whether d fone is working smoothly if not chnge settings to default.. . Like wise u can differnt settings n... nd Dnt click on apply on reboot while chking it
Sent from my Spice MI-350n using XDA
Click to expand...
Click to collapse
OK thanks but you explain the general concept of overlocking and tweaking, at the level of correcting voltages table... But my questions, they haven't been answered yet..
Anybody?.... who can help?
Отправлено с моего Cynus T1 через Tapatalk
I have same problem.. UPUP!!
+1
MTK6577 CPU here (MTK CPU Control does not work on MTK6577)
zerno said:
Hello to all of you!
I've honestly searched the web and particularly this forum to find questions related to my current problem - finding the best settings for my phone's CPU that will fully suit me.. But there are also answers I've failed finding myself.
So, I have an Android mobile phone, Mobistel Cynus T1, which is MTK6577-powered. And I want to tweak its CPU controlling (assume that I already understand what all of that 'governors' and 'i/o shedules' stand for) with, let me say, the app SetCPU. The phone has been rooted already.
So, I installed this app and chose Continue Recommended in a pop-up window when launching for the first time, and the next frequencies and governors and shedules were defined for my phone:
Freqs: 250 500 667 750 834 1001 MHz
Governors: ondemand, userspace, powersave, hybrid, performance
i/o shedulers: noop, cfq, deadline
Here are the questions (sorry if the intro was useless or unnecessary, but I thought it is needed):
What is that 'hybrid' governor? I really couldn't find even a mention of it.
That upper list of freqs, are these freqs show the full range od freqs available for MTK6577, or not? If not, what freqs could be added?
What freq is the most energy efficient for MTK6577? I am asking this because I've read in some thread in xda-forum that the lowest freq doesn't mean the lowest battery consumption.
The 'powersave' governor, does it automatically finds the most most energy efficient freq or just sets the lowest? (referring to 3rd question)
If i set 'cfq' for all the profiles and 'noop' for screen-off profile, is it okay and wouldn't such a combination of shedulers harm my device?
Now come questions that as I think are related to the SetCPU app rather than to tweaking CPU in general:
My current working profile is 'CPU 250-834, hybrid, cfq'. Why than I often see that the proc increases its freq to 1000MHZ? There is no conflicting app and the SetCPU was allowed via a root-allowing app.
For the 'hybrid' governor, there are some settings which explanations I couldn't find:
down differencial
ignore nice load
io is busy
load critical grade
load high grade
load warning grade
load medium grade
load light grade
load critical
load high
load warning
load medium
load light
load up bound
load down avg times
Thank you for reading all this and double thanks for helping
Click to expand...
Click to collapse
Hi mate, I have the acer Liquid E1, with the same processor. have a look at this thread, it might clear up some things for you
http://forum.xda-developers.com/showthread.php?t=2186957
The app in the link below seems to work with MTK6577
http://forum.xda-developers.com/showthread.php?p=39041733
Hello, I'm new on this forum then I'm sorry if i post in a bad section for my questions... But I think I should post here.
I've got several questions:
- Is there really no risk about undervolting CPU, I asked me about this because no one forum tell risk but compagny thaty produces phones don't set the minimal voltage required for each frequencies.
- Is there an app to force CPU usage at 100% to test undervolt options.
Example: I undervolt 2265MHz with -50mV, I launch app, click on 100% uage then it use at 100% my CPU, if it crash undervolt is to high. If it don't crash undervolt is good, maybe continue tu undervolt.
- Is there an automatic app to undervolt ?
Example: It decrease 1mV by 1mV with always the same frequencie of CPU and 100% CPU usage then when phone crash it restore the last value of voltage, then it do it with another frequency etc etc ...
- Which voltage do you use ? And are there voltages the same for all nexus 5 or they will change depending of each processor.
To give me an opinion about what to use
- If I found a minimum voltage, will it be the same for all kernel ?
Example: I'm on Kernel A, my min for 300MHz is 725mV, I switch to kernel B, Will it work with 725mV for 300MHz??
More generally it depend only of the processor or also of the kernel, governor, I/O scheduler ??
I Think it's all maybe other questions will come
I Thank you for all your constructive response. Don't hesitate to ask me to develop certain question and tell me mistakes .
Theres an undervolting thread. Should be linked in the "Sticky roll-up thread" which you can get to via my signature
Okay, thank you
Okay, I will copy/paste my message
Thak you for the information.
This guide is meant for ALL smartphones that runs the Interactive governor, copy-pasted here for better visibility. Credits goes to @soniCron for starting up the guide and @Alcolawl for further implementing it.
The Introduction
So, I tried copy-pasting the entire thread and realised it looks ugly therefore I'll rewrite it to be more simpler and straightforward.
Imagine a car with manual gears, you choose what speed is best suitable for the road conditions. Going into a curve? Best slow down. Clear straight road? Go fast so you reach the destination safely and efficiently.
That's what this guide aims to do with the Interactive governor, based on the CPU load it will choose the best and the lowest frequency to complete the task without compromising performance.
For example, if you scroll your Facebook page your CPU might clock up to the highest frequency for smooth scrolling. Now lower the frequency one step down and you may find that it's still smooth, so why isn't it choosing that instead? Don't blame the phone companies or Google, that's just a way of ensuring performance at all times. This guide will push the limits of that capability.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Click to expand...
Click to collapse
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing lags or stutters. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
Remember what was said about scrolling FB pages? This is it.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
Imagine a staircase with steps of different heights. You climb these stairs better depending on the height of each steps, do you skip some steps if you can reach the next one easily? Or do you take one step at a time because they are too high?
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 384Mhz
Page Scrolling - 600Mhz (Tested by browsing FB on Chrome browser cause they're intensive enough)
Video - 787Mhz (Same thing, watch 60fps videos on different resolutions on the Youtube app to detect stutters and lags)
App Loading - 960Mhz
High Load Processing - 1440Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Nexus 5X. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 384Mhz nominal
Page Scrolling - ???Mhz efficient / 600Mhz nominal
Video - ???Mhz efficient / 787Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1440Mhz nominal
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Nexus 5X, the maximal efficient loads of CPU 1 are:
384000:75
460000:69
600000:80
672000:76
787000:81
864000:81
960000:69
1248000:78
For the Nexus 5X, the minimal efficient loads of CPU 1 are:
384000:0
460000:19
600000:30
672000:12
787000:17
864000:9
960000:11
1248000:30
1440000:15
For the Nexus 5X, the maximal efficient loads of CPU 2 are:
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:83
1344000:84
1440000:84
1536000:84
1632000:86
1689000:83
For the Nexus 5X, the minimal efficient loads of CPU 2 are:
384000:0
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1689000:3
1824000:8
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That 2nd CPU?!
So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
384Mhz
1248Mhz
1824Mhz
In this case, we configure it just as we did with CPU 1, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhz immediately when needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.
These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
For the Nexus 5X, we'll jump straight to...
The Money Shot: Part Deux
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 2. ("big"–the one with 2 cores)
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1824000
min_sample_time - 20000
target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95
timer_rate - 20000
timer_slack - 80000
Click to expand...
Click to collapse
SO there you go, that's the gist of it. I got some smaller examples written up later so hopefully it's more understandable.
"I'm Too Lazy To Read All That! WHAT DO I NEED TO DO?!?!"
If you own a Nexus 5X or 6P, install the ElementalX Kernel and the EX Kernel Manager. (Yes, it works in other kernels, but you're on your own regarding how to set the values. Other kernel editors, such as Kernel Adiutor, are currently buggy and problematic, so your mileage may vary. And if you have another device, you must follow the instructions in this post to derive your own values.)
UPDATE: EX Kernel Manager now supports governor profiles and most currently published profiles are distributed with the manager. To access: EXKM> CPU> Governor options> Load, then select the profile you wish to try! Many thanks to @flar2 for providing native support!
ALPHAS – USE AT YOUR OWN RISK!! (Actually, we really like "GostPepper". Try it out. It's spicy! And don't worry–it won't break anything!)
GlassFish (For most devices!) - High battery savings with buttery smooth interface!
HawkTail (6P) - An advanced, modern profile that is both battery efficient and highly performant! All users are urged to check out HawkTail!
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile.
GhostPepper (6P) - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. The current favorite, albeit not very well tested so far. HIGHLY RECOMMENDED
SilverFish - Effectively eliminates "hispeed_freq" so perceptive scrolling performance is increased, giving the illusion of excellent performance while providing great battery life. Some users experience problems with performance while multitasking--NOT RECOMMENDED FOR EVERYONE. Light users should enjoy this very much, however.
MadDog - The first major departure from the core strategy. Very well tested, extremely stable, and HIGHLY RECOMMENDED if you aren't fully satisfied with v2.0 settings. This is on the table to be the next stable v3.0, so rest assured you can't go wrong with this one!
DrunkSauce - Supreme UI fluidity coupled with excellent active and idle battery drain. Idle Drain was consistently measured to be ~1%. And while I don't rely on SOT figures that people constantly throw around, active drain spanned from 15-20%/hr depending on usage. YMMV. And as always, flawless audio playback for you audiophiles and ARISE users out there.
Those are the ones compiled for now, please remember that these are all up to the users' preference. It will improve YOUR own SOT, not straight up 8 hours on every device. You can copy off the profiles and use your own device frequency and target loads, use an app like Kernel Auditor to help edit them. It works for stock and custom roms too.
Extra credits:
Thanks also to:
Every developer who has seen this guide, modified it, and implemented it.
All the members who contributed and argued about the inner workings of this guide, your constructive feedback is amazing and helped fine-tune future profiles.
To the poisonous and toxic trash member(s) of a certain thread for their lack of help and elitist behaviour. Their embarrassing attitude helps open our eyes to the dos and don'ts of internet manners.
This is for calculating target loads.
Let me give you an example from my Note 1:
My clock rates are (in MHz): 200, 500, 800, 1000, 1200, 1400
Their voltages are (in V): 950, 950, 1050, 1125, 1225, 1300
If I were to plot the differences in voltage, it would appear like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
From the graph, 500MHz to 800MHz has a huge difference in voltage increase compared to 1000MHz to 1200Mhz. That frequency BEFORE the huge jump is the efficient clock rate: 500MHz and 1000MHz.
So, the nominal clock rate on the other hand is the minimum frequency you can use to complete a task (such as watching videos, loading apps, page scrolling). In this case, mine are: 200MHz, 800MHz, 1000MHz
Now, we just calculate (from the first post) the minimal efficient loads for efficient clock rate and maximal efficient loads for nominal clock rate.
That means my target loads will be:
500: 60
800: 72
1000: 75
1200: 17
I skipped the calculations but this will be what it looks like from there. Someone pls do let me know if I made a mistake, as it does tend to confuse people with other devices.
Nominal clock rate: Maximal load
Efficient clock rate: Minimal load
Edit: Those are for the target loads, for the rest of the settings I'll use the profiles'.
Eh, mmight as well reserve this too
Nice looking guide, about to read
wtf,you just copy pasted in the end
Nice beginning, but half is missing, and you are referencing things that haven't been done before
Hi Guys, this is a continuation from initial discussion (and my promise) on InsigniuX kernel thread HERE
UPDATE 1 : After further testing, incorporate input boost to CPU 1 and 5 actually help the performance without affecting battery, as long as we set it within the optimal frequency. I also put fine tuning in hispeed_delay value, please use latest Profile File if you are using PRESET, or check the new values bellow if you do manual config
NOTE : If you are too lazy too read all the technical stuff, simply download the PRESET KERNEL ADIUTOR PROFILE HERE, and apply it to your Kernel Adiutor (choose "profile" from side bar, hit the (+) icon, and choose "import" and choose the downloaded .json file)
as we all know and aware, we always look and try to find the most optimum configuration to achieve best battery life without sacrificing performance. And while of course Qualcomm and Xiaomi have the most talented developers in their team, sometimes the implementation between both in their mass product might left a room for improvement. And in that exact room, we as community here play our role,
so, in an attempt to get a better fluidness out of this device, without sacrificing battery life, i remember one of the guide made by @soniCron i used to stumbled upon few years ago. This Guide give a very detail insight on how to optimize the interactive governor on almost any device/any kernel/any rom (as long as you have root), and thats what i gonna try to apply to our device - if you want to check the guide yourself : HERE
so i take a look into Whyred Kernel Sources to see the voltage values being used by our processor for each frequency step. And here's the voltage/speed table in case you want to see :
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
from that table, we can see which frequencies are using most power, and where is the most jump in voltage usage happen when switching between frequency.
Higher voltage jump will cost more power, means less battery life.
in conclusion, i found few frequencies which are less favorable, which is
LITTLE CPU :
1136Mhz - step by step Speed Gain is fine, but when compared to straight jump to 1401Mhz, the Speed to Power Ratio is become less favourable
1536Mhz - Smallest Speed Gain compared to Power Usage
and i also found some which might be the best/favourite frequencies :
LITTLE & BIG CPU :
900Mhz - Best contender for base speed, as it use almost same power with 633Mhz, but with plenty of speed gain
1401Mhz - Good Speed to Power Ratio
and
1747Mhz - Good Speed to Power Ratio for BIG CPU
_____________________________________________________________________________________________________________________________________________________
Now we take into account of the minimum frequency needed to ensure smooth task (if you dont know what am talking about, read the GUIDE i mention in my opening paragraph) :fingers-crossed:
For Whyred, i've found the best frequency is as following :
Idle = 633MHz (Lowest we can go at the moment)
Scrolling = 900MHz (Use Chrome browser to scroll Facebook in desktop mode)
Video = 1401MHz (Play 1080p*60fps videos in Youtube app)
App load = 1747MHz (Can use any app really)
High load = 1843MHz (Max out just in case)
Using the formula take from soniCron guide, i tried calculate optimum CPU load (this will be used as target load config) config for each frequencies
If you want to see the formulas :
Code:
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
with this config, logically speaking we want to make the Governor to favour the "best" frequencies above, and minimize the usage of unfavourable freqs.
LITTLE
Code:
633Mhz : 63
900Mhz : 71
1136Mhz : 23
1401Mhz : 82
1536Mhz : 4
1612Mhz : 83
BIG
Code:
1136Mhz : 73
1401Mhz : 9
1747Mhz : 85
1843Mhz : 90
Now that we already get the optimum number, time to apply it
Use your favorite Kernel Manager, in my case, am using Kernel Adiutor, and go to CPU Config - CPU Governor Tunables and input these value (am using Hawktail base profile from soniCron thread, as it seems it work best for most of devices, and i already do trial & error with some other value like timer rate as well ) :
(LITTLE)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 0 633600:60000 902400:75000 1401600:100000
timer_rate: 80000
hispeed_freq: 902400
timer_slack: 200000
target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
min_sample_time: 35000
boost: 0
boostpulse_duration: 0
(BIG)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 32000 1136000:60000 1401600:75000 1747200:80000
timer_rate: 60000
hispeed_freq: 1747200
timer_slack: 100000
target_loads: 98 1113600:23 1401600:9 1747200:85 1804200:94
min_sample_time: 20000
boost: 0
boostpulse_duration: 0
Other necessary adjustment :
Boost : ON For CPU 1 at 902400 and CPU 5 at 1401600 both for 100ms
Min Big CPU Hot Plug : 0
Disable all Toggle in Thermal Section
Run Terminal and command :
Code:
su
stop perfd
or Install this MAGISK MODULE to disable Stock Thermal & Hotplug Control (Courtesy of @Mr.Nguyen0504)
Now you can test it. Do full charge and use it normally, see whether you can see the improvement or not,
be mind that this config is not really adjusted towards battery life, but rather overall fluidness/performance, yet without sacrificing too much power
Hopefully it helps you as it seems to help me (you can expect no less than 7-8Hrs SoT, am quite heavy user myself, with 2 WhatsApp account and 1 LINE account constantly active. YouTube & Gaming at least hour/day as well). Discussion is more than welcome here, as these are considered an initial calculations that still yet to furtherly fine tuned for our CPU.
Thanks mate, was waiting for this.
Initial thoughts = project butter:good:
xdarkstar said:
Thanks mate, was waiting for this.
Click to expand...
Click to collapse
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
otonieru said:
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
Click to expand...
Click to collapse
Excellent guide as well. Will test parameters over the weekend.
I will test this
mxilil said:
I will test this
Click to expand...
Click to collapse
yes please,
in the meantime, i also testing another config with input boost enabled, and some fine adjustment to hispeed_delay,
if it turn out to be better, i might create 2nd preset, along with custom control to disable BCL and Perfd. So we do not need to type it in terminal manually after reboot and let adiutor do that.
otonieru said:
Run Terminal and command :
Code:
su
stop perfd
Click to expand...
Click to collapse
I think "stop perf-hal-1-0" is the proper command.
@otonieru Great thread, very nice presentation of the matter with just the right info and setup example.
I have followed the same tutorial for my previous device but ended up using the tunables from my ROM maintainer as I never managed to calculate it properly, probably because I overlooked the voltage jumps.
Now, I wonder whether the minimum freqs of 300mhz for both clusters would help in battery life gains, taking into account the proper target loads are set for both and "timer_rate" and "min_sample_time" are tuned to make CPU ramp up quickly to avoid lags and stutters.
Logically, voltage is lower for lower frequencies, but in this case, 300mhz and 633mhz might be the same on little cluster or the voltage jump might be insignificant, but the voltage jump on big cluster might be bigger. And since the big cluster is on minimum frequency most of the time we might see some gains there.
Can you check the sources of some kernels with full range of frequencies (not the ones who have undervolt applied) and see the voltage tables?
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
Code:
[init.svc.perfd]: [running]
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Cirra92 said:
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Click to expand...
Click to collapse
Actually, i didnt include 300Mhz in my calculation because i try to check various whyred kernel source, and found that not too many of them make the 300Mhz available to beanually selected, but i do check the voltage used by 300Mhz and its saving is almost neglectible,
and as i do this tweak based on my current kernel set up (InsigniuX), i do it with 633 as base.
as for 1612 being used much,
i found that there's probably a bug in our device kernel code that make cpu sometimes lock in its highest frequency (1804 & 1612), it only happen after you restart the phone, (and it happen with most kernel out there, so its not literally the dev mistake, more like xiaomi messed up some codes)
the fix for now is by opening adiutor, ensuring that the freq not locked up. If its locked, change it back manually to 633 and 1133 (for small and big respectively), i found that it manage to stay until another reboot.
my cpu usage is as how i expected from my target load. so i think it play nicely for now.
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
I am still on first charge since tweaking the kernel. So far it seems that the battery life is going to be the same, but it feels to me that everything is just a bit faster now, app opening and loading times are shorter and a bit smoother, might be a placebo, but it works nice.
One thing you should fix in main post, your target load for 1612 mhz in little cluster is set to 8, but in calculations it is 83, I suppose you missed the 3 when you wrote the tunables
I am going to update the settings you added after it falls to 20% and I recharge it.
One more thing, if I use the Magisk module for thermal and hotplug (or simply turn off the Core control in Kernel manager) does it mean that the cores will go offline if there is no load?
I remember having different hotplug solutions on SD801 devices which actually turned off 3 cores and left only one to do basic functions in deep sleep, or turn on 2 of them when there is low load on the CPU.
@Cirra92 ah right ! i might hit the backspace accidently, LoL
about hotplug, honestly am still testing it myself to figure whether the config work as intended or not, since the behaviour of this chipset it quite different. And since oreo its a bit harder to really track the cpu activities, we need to run an app to see the activities, but the app itself is giving load to cpu, thus the reading might not actually accurate.
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
blackbellz said:
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
Click to expand...
Click to collapse
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
crap, i cant even attach 2 picture in one post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
Can you add an image of the voltage table? The original image is not visible^^
otonieru said:
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
Click to expand...
Click to collapse
i tought this was towards battery but still keeping performance.
Try it or die said:
Can you add an image of the voltage table? The original image is not visible^^
Click to expand...
Click to collapse
Yup, it's not visible. But OP said its visible to him...
raptorddd said:
i tought this was towards battery but still keeping performance.
Click to expand...
Click to collapse
no, its the other way round as i wrote in my main post, LoL. But i guess 9-10Hrs SoT is more thwn enough wasnt it ?