Thanks for verifying that for me Andrei. The mod I did is here in case anyone is wondering what I'm talking about (LOL)> http://xdaforums.com/showthread.php?t=1951493
[Kernel][Apr 26] Perseus
- Thread starter AndreiLux
- Start date
-
- Tags
- development
Just reinstalled on odin'd stock ROM - made it faster (max OC) and am again trying -50 UV.
Will this have further development? You apparently ported over a pretty well developed kernel and I have not run into any problems - was just curious.
Will this have further development? You apparently ported over a pretty well developed kernel and I have not run into any problems - was just curious.
I personally like the kernel, but this is the first time I see so many exposed variable for me to change on it in SetCPU. Is there anywhere I can read like a guide or something to what all of them do?
I know the more common ones, but even that's less than 10% of them...
Sent from my SGH-T889 using xda app-developers app
I know the more common ones, but even that's less than 10% of them...
Sent from my SGH-T889 using xda app-developers app
I will update all kernel variants including the one here when there's updates to the main kernel. If you're missing a few point releases which the other variants have then it means that it's not important or not affected by the changes.
I suggest reading the main thread linked in OP for more explanations. If you don't understand some of the configurables then it's advised you don't change them either, as they're already set up in a good fashion.
Help with Perseus kernel settings
I checked the original thread, but it's 100 pages long; It'd take me forever to go through it. I like understanding the settings so I can custom tailor things to my liking; and the variable names themselves aren't very indicative of what they change to someone who hasn't seen them before. But if I can't find a table showing the variables and what they represent, then I hope at least I can get some help with a specific change I'd like to do.
I ask because I am noticing a bit of a pause when it ramps up the processor from idle. I notice it most when I swipe the home screen using ADWLauncher EX. The first swipe sort of chugs a bit, but afterwards it becomes glass smooth, so I figure it's a ramping issue where the kernel's wound down the cores to rest and when I interact with it it's not winding them up again fast enough; probably not stepping up fast enough.
I want to change the settings a bit so that in the initial step it'll wind up over what's necessary, and then wind down to what's needed. It'll improve apparent response time, and with how much this battery lasts, spending a bit more is not an issue to me. Any idea or help on doing this change will be very appreciated.
Thanks for any help, and my apologies if this has been answered before; the forums are a bit hard to navigate sometimes.
I checked the original thread, but it's 100 pages long; It'd take me forever to go through it. I like understanding the settings so I can custom tailor things to my liking; and the variable names themselves aren't very indicative of what they change to someone who hasn't seen them before. But if I can't find a table showing the variables and what they represent, then I hope at least I can get some help with a specific change I'd like to do.
I ask because I am noticing a bit of a pause when it ramps up the processor from idle. I notice it most when I swipe the home screen using ADWLauncher EX. The first swipe sort of chugs a bit, but afterwards it becomes glass smooth, so I figure it's a ramping issue where the kernel's wound down the cores to rest and when I interact with it it's not winding them up again fast enough; probably not stepping up fast enough.
I want to change the settings a bit so that in the initial step it'll wind up over what's necessary, and then wind down to what's needed. It'll improve apparent response time, and with how much this battery lasts, spending a bit more is not an issue to me. Any idea or help on doing this change will be very appreciated.
Thanks for any help, and my apologies if this has been answered before; the forums are a bit hard to navigate sometimes.
ADWLauncherEX is glass smooth on the stock kernel but not with this?
Sent from my SGH-T889 using Tapatalk 2
Sent from my SGH-T889 using Tapatalk 2
The only launcher I've seen be perfectly smooth is the touchwiz one. Everything else stutters a bit. I'm pretty sure it's because touchwiz is cheating, though, keeping everything in ram or something. And I only notice for an instant in the desktop. Trust me, it's barely noticeable; I'm just anal for these kind of things.
Which would imply the CPU isn't the issue. Memory, or the scheduler? I'm not sure, I'll need to research more. Still, I'd prefer to configure the kernel using it's exposed settings to be more responsive than battery-conscious. But again, that's just me.
Sent from my SGH-T889 using xda app-developers app
Which would imply the CPU isn't the issue. Memory, or the scheduler? I'm not sure, I'll need to research more. Still, I'd prefer to configure the kernel using it's exposed settings to be more responsive than battery-conscious. But again, that's just me.
Sent from my SGH-T889 using xda app-developers app
I guess I had to write this some time or another. I just also put this into the main thread.
sampling rate
The default time in-between governor scaling "ticks" where the governor checks CPU load and triggers its scaling logic. Measured in milliseconds (ms).
up threshold
The threshold percentage of load from the last sampling window in which the governor triggers its up-scaling logic.
sampling down factor
If the up-scaling logic reaches the max policy; i.e. the maximum allowed frequency, the governor will disregard all logic for x amount of samples and stay at that frequency until we do another scaling sample.
ignore nice load
Processes with higher priorities can have an augmented reported load value, but we can differentiate this and ignore them if this is checked. Keep it at 0.
io is busy
I/O interaction is seen as a CPU load bearing activity. This isn't true for our architecture so keep it at 0.
down differential
The CPU down-scaling logic threshold is triggered if load is less than (up threshold - down differential). The down differential acts as a buffer so that we don't uselessly scale back up in near threshold level loads. If the down-scaling conditions are met, the CPU will take the current CPU load and derive the next best frequency that would accommodate that frequency without triggering an up threshold.
freq step
When the up-scaling logic is triggered the governor dictates the CPU to raise its frequency by (max policy * (freq step / 100)). If max policy is currently 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, 336 becomes 400. If we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz.
cpu up rate
The amount of samples the hotplug logic will collect before it makes a hotplug decision to bring up a CPU.
cpu down rate
The amount of samples the hotplug logic will collect before it makes a hotplug decision to bring down a CPU.
up nr cpus
If the hotplug logic decides we need to bring CPUs up, the amount of CPUs we bring up at once is being dictated here.
max cpu lock
The maximum allowed amount of CPUs allowed to be up at the same time.
min cpu lock
The minimum allowed amount of CPUs allowed to be up at the same time.
hotplog lock
If set other than 0, locks the CPU up count at the specified amount.
dvfs debug
DVFS and hotplug debug is printed out in /proc/kmsg if this is enabled.
hotplug freq x y
Hotplug frequency threshold which decide if we should trigger a hotplug-up or a hotplug-down. X marks the current amount of cores. Each state has a trigger-down (Y = 0) or a trigger-up (Y = 1) condition.
Example: "hotplug freq 3 0 500000" If there are currently 3 cores up, and the frequency gets below 500MHz and the hotplug rq 3 0 conditions for this state are met too, then bring down the core count to 2.
hotplog rq x y
Similar to the hotplug freq conditions in syntax, only that here we are measuring the amount of threads waiting in the kernel runqueue as opposed to frequency. The kernel runqueue is a queue where threads are waiting to be executed. Every cpu up rate or cpu down rate amount of samples, we accumulate the average snapshots of amount of threads in every sampling window. The value itself is this average, just in integer form multiplied by 100. If set to 175 for example, we need to have at least 1.75 threads running over the last cpu-(up/down)-rate * samples to trigger the condition. Live statistics can be extracted by enabling dvfs_debug to see this.
up threshold at min freq
We have the scaling frequencies divided in two parts: ones governed by up_threshold and ones governed by up_threshold_at_min_freq. We want the CPU to get out of the lower frequency states faster to improve fluidity, and also to improve power consumption as the lower power states are more inefficient in perf/power for fixed load tasks over time. The same logics apply as with up_threshold.
freq for responsiveness
Frequency threshold below which up_threshold_at_min_freq is taken instead of up_threshold.
flexrate enable
Enable flexrate requests. Flexrate requests temporarily dramatically raise the sampling rate / lower the sampling period.
flexrate forcerate
Ignore in-putted values given to the governor and use this instead as the accelerated rate.
flexrate max freq
Frequency threshold above which flexrate requests are ignored.
flexrate num effective usage
A statistic of amount of samples taken at the accelerated rate.
lcdfreq enable
Enable LCD frequency scaling.
lcdfreq kick in down delay
The amount of samples below kick-in-freq the CPU must reside for it to switch to the lower display frequency.
lcdfreq kick in freq
The threshold frequency below the CPU must be for the display to switch to lower display frequency.
And for what it matters, I find Nova Launcher the smoothest of them all.
Last edited:
Another question. The cores consume power individually, right? So is it more efficient, given power consumption per clock speed, to ramp up a core than turn on another one?
I figure I can tweak in order to ramp up a single core fast, and if the load persists, then begin turning on more cores. Does that make any sense?
I figure I can tweak in order to ramp up a single core fast, and if the load persists, then begin turning on more cores. Does that make any sense?
Everything I did not really want to know and was not going to ask - lol - trust thy developer! I do - so I only mess with OC, UV, voltage, and screen off, on call, etc.
With these settings I had mentioned earlier, I am finding a significant improvement in battery life on this kernel. Nice work.
With these settings I had mentioned earlier, I am finding a significant improvement in battery life on this kernel. Nice work.
Nothing to do with trust. Would I be using the kernel if I didn't? But not everyone uses their phone the same way, or wants the same from it. This is the first kernel I have fallen in love with, if only because of all the exposed controls and how I can fine-tune it's functions to do exactly what I want it to do.
Thank you very much for this informative post!! Looking forward to rooting this weekend and running your kernel
I have one question though, for gpu overclock its through an init.d script right? Also what are the clock values that can be set?
Sent from my SGH-T889 using Tapatalk 2
The power efficiency curve breaks even at 600-800MHz for single core scaling so at that point it is more efficient to bring up another core if load stays stable so you can stay in the "valley" of the power curve. Remember that bringing up a core takes 80-150ms depending on load because of the idiotic and archaically inefficient kernel overheads while a frequency switch takes up only about 100µS so we're talking about 3 orders of magnitude difference in latency.
I generally say this to people: leave the settings as they are. You can play with freq_step and slightly raise it for a bit more responsiveness if you want to, but that's about it.
Check the main thread for GPU explanations. Valid values are also listed there if you want to change the frequency steps themselves.Thank you very much for this informative post!! Looking forward to rooting this weekend and running your kernel
I have one question though, for gpu overclock its through an init.d script right? Also what are the clock values that can be set?
Sent from my SGH-T889 using Tapatalk 2
Last edited:
Thanks, AndreiLux. Really appreciate your time and attention. I'll play with the freq_step then. ^_^
Similar threads
- Poll
Top Liked Posts
-
There are no posts matching your filters.
-
105This is a direct port of my kernel on the international I9300 Galaxy S3 and sidekick to the international N7100/5 Note 2 kernels.
Recap of features:
- CPU overclocking up to 1.8GHz and undervolting from 600mV to 1400mV.
- GPU overclocking and undervolting.
- GPU scaling reworked.
- Screen sharpness and colour modifications.
- Extended Pegasusq and improved Performance governors.
- Removed Touch Booster and replaced with custom Flexrate mechanic.
- Improved scheduler power management for improved idle residencies on auxiliary CPUs.
- USB charging rate limit increased to 900mA.
This is supposed to be merely a proxy thread. Please refer to the N7100/5 thread for full changelogs, explanations, bug-reports and other issues. Kernel for specific device versions will be posted here.
This kernel is for the North American T-Mobile variant SCH-T889. Versions for other variants are found in their respective forums.12
I guess I had to write this some time or another. I just also put this into the main thread.
sampling rate
The default time in-between governor scaling "ticks" where the governor checks CPU load and triggers its scaling logic. Measured in milliseconds (ms).
up threshold
The threshold percentage of load from the last sampling window in which the governor triggers its up-scaling logic.
sampling down factor
If the up-scaling logic reaches the max policy; i.e. the maximum allowed frequency, the governor will disregard all logic for x amount of samples and stay at that frequency until we do another scaling sample.
ignore nice load
Processes with higher priorities can have an augmented reported load value, but we can differentiate this and ignore them if this is checked. Keep it at 0.
io is busy
I/O interaction is seen as a CPU load bearing activity. This isn't true for our architecture so keep it at 0.
down differential
The CPU down-scaling logic threshold is triggered if load is less than (up threshold - down differential). The down differential acts as a buffer so that we don't uselessly scale back up in near threshold level loads. If the down-scaling conditions are met, the CPU will take the current CPU load and derive the next best frequency that would accommodate that frequency without triggering an up threshold.
freq step
When the up-scaling logic is triggered the governor dictates the CPU to raise its frequency by (max policy * (freq step / 100)). If max policy is currently 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, 336 becomes 400. If we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz.
cpu up rate
The amount of samples the hotplug logic will collect before it makes a hotplug decision to bring up a CPU.
cpu down rate
The amount of samples the hotplug logic will collect before it makes a hotplug decision to bring down a CPU.
up nr cpus
If the hotplug logic decides we need to bring CPUs up, the amount of CPUs we bring up at once is being dictated here.
max cpu lock
The maximum allowed amount of CPUs allowed to be up at the same time.
min cpu lock
The minimum allowed amount of CPUs allowed to be up at the same time.
hotplog lock
If set other than 0, locks the CPU up count at the specified amount.
dvfs debug
DVFS and hotplug debug is printed out in /proc/kmsg if this is enabled.
hotplug freq x y
Hotplug frequency threshold which decide if we should trigger a hotplug-up or a hotplug-down. X marks the current amount of cores. Each state has a trigger-down (Y = 0) or a trigger-up (Y = 1) condition.
Example: "hotplug freq 3 0 500000" If there are currently 3 cores up, and the frequency gets below 500MHz and the hotplug rq 3 0 conditions for this state are met too, then bring down the core count to 2.
hotplog rq x y
Similar to the hotplug freq conditions in syntax, only that here we are measuring the amount of threads waiting in the kernel runqueue as opposed to frequency. The kernel runqueue is a queue where threads are waiting to be executed. Every cpu up rate or cpu down rate amount of samples, we accumulate the average snapshots of amount of threads in every sampling window. The value itself is this average, just in integer form multiplied by 100. If set to 175 for example, we need to have at least 1.75 threads running over the last cpu-(up/down)-rate * samples to trigger the condition. Live statistics can be extracted by enabling dvfs_debug to see this.
up threshold at min freq
We have the scaling frequencies divided in two parts: ones governed by up_threshold and ones governed by up_threshold_at_min_freq. We want the CPU to get out of the lower frequency states faster to improve fluidity, and also to improve power consumption as the lower power states are more inefficient in perf/power for fixed load tasks over time. The same logics apply as with up_threshold.
freq for responsiveness
Frequency threshold below which up_threshold_at_min_freq is taken instead of up_threshold.
flexrate enable
Enable flexrate requests. Flexrate requests temporarily dramatically raise the sampling rate / lower the sampling period.
flexrate forcerate
Ignore in-putted values given to the governor and use this instead as the accelerated rate.
flexrate max freq
Frequency threshold above which flexrate requests are ignored.
flexrate num effective usage
A statistic of amount of samples taken at the accelerated rate.
lcdfreq enable
Enable LCD frequency scaling.
lcdfreq kick in down delay
The amount of samples below kick-in-freq the CPU must reside for it to switch to the lower display frequency.
lcdfreq kick in freq
The threshold frequency below the CPU must be for the display to switch to lower display frequency.
And for what it matters, I find Nova Launcher the smoothest of them all.7
You either have power savings mode turned on or there is something else wrong in your side settings wise. The kernel is fine. Also the benchmarks you did were perfectly normal, and you're just pulling those One S scores out of your ass:
http://www.glbenchmark.com/compare....ified_only=1&D1=Samsung GT-N7100&D2=HTC One S
I cannot make the phone break the VSync barrier, I already explained this.
I would ask if you stopped posting as you're babbling about non-existent issues and reading your writing style makes my eyes hurt.
