Hello all !
I was bored in school today so I've written a governor concept idea for quad cores. I'm not a dev AT ALL (for now at least, i'm studying many different stuff, hardware / code related too).
I have no idea if this is possible or if this is clever but I wanted to share it anway. If it gives idea to a developer, that's totally worth it, otherwise, well... I had fun doing it
It's called Progressive.
Progressive
The name of the governor says all. The idea behind it is to be «*progressive*». It means it doesn't unleash the full power when it's not needed. It goes progressively higher in freq with more cores. This should make the phone cooler and the battery better. The delay (3 sec ) is just a number, not sure this is really nice. Also, I'm not sure how the S4 handles temperature.
Max freq 1.5 Ghz
Min freq 384 Mhz
Screen off
=> 384-918 Mhz // not too low frequency to avoid reboot
Screen on without touching since 3 sec // always check after 3 seconds for changing the state
=> 384-1134 Mhz only one core online
Screen on touched
=> 594-1134 Mhz two cores online // bump the min_freq to avoid keyboard lag and to add a bit of butter
Screen on touched with a medium load of task // not sure how quantify this
=> 594 Mhz – 1.5Ghz two cores online
Screen on touched with a high load of task // i.e. Games
=> 702 Mhz – 1.5 Mhz four cores online // max power
We also need a thermal protection to avoid any damage, this should do the trick
If the temp is >= 80°C
=> Two cores online max_freq 1134 Mhz until it reaches 70 °C // not sure about the temp, this can be adjusted
If the temps is >=70°C
=> Let 4 cores being possibly online but lower the max_freq to 1134 Mhz
Click to expand...
Click to collapse
What do you guys think ? Is this even possible ? Good, bad idea ?
I hope you enjoy reading it as much as I enjoyed to writte it
doesn't it do this already?
Fissurez said:
doesn't it do this already?
Click to expand...
Click to collapse
I'm not sure how the ondemand governor on nexus 4 works. So I can't really answer, it's really a noob idea that poped into my head today
you pretty much described interactive with mpdecision enabled.
not exactly, but quite.
3 seconds is way too long for the CPU to ramp up (just a matter of tweaking, though). you'd get more lag than you save battery.
mpdecision ramps the cpu to its maximum frequency as soon as a touch input is detected (normally only 2 cores until a certain threshold is reached), so yours should save a bit of power during smaller workloads.
also, if the touch input is released, it clocks the active cores down to 1.02 GHz for a bit before disabling them when not needed.
after all, it seems like a more conservative interactive governor with active mpdecision. could be nice for saving battery while retaining good performance.
it could be a viable choice for those who go for battery life over performance. :good:
Nuu~ said:
you pretty much described interactive with mpdecision enabled.
not exactly, but quite.
3 seconds is way too long for the CPU to ramp up (just a matter of tweaking, though). you'd get more lag than you save battery.
mpdecision ramps the cpu to its maximum frequency as soon as a touch input is detected (normally only 2 cores until a certain threshold is reached), so yours should save a bit of power during smaller workloads.
also, if the touch input is released, it clocks the active cores down to 1.02 GHz for a bit before disabling them when not needed.
after all, it seems like a more conservative interactive governor with active mpdecision. could be nice for saving battery while retaining good performance
Click to expand...
Click to collapse
Thank you Sir, I understand better how mpdecision works now
Glad to see i'm not completely stupid lol
hi all
im using DooMKernel for a while and when i set the maximum frequency for any speed faster than [email protected], when the cpu is on heavy load or when the phone temperature is rising above some threshold (i think it's around 45 degrees, not sure tho) - there is an automatic down throttling to stock valus (max 1.5ghz) and nothing will recover it back to modified values unless reboot or reapplying the OC via SetCPU or equivalent.
now, i know there is a 'thermal control' sort of mechanism, and i also know it probably resides both on os level and sony framework, but i wish i could disable it somehow.
i know there is a great risk of frying my XZ, but im only intend to overclock for short terms and not for a main daily usage.
a quote from DooMLoRD's post on the subject:
It has been observed that the overclocking sometimes reverts back automatically to stock settings especially after heavy CPU load and if the device heats up.
I think have found why this happens:
Android OS level
there is a binary called: /system/bin/thermald which writes lower CPU freq values to the CPU sysfs interface if the device starts heating
there is also an app "Overheat Control" which i suspect is doing something similar
Kernel level
there seems to be some sort of fail-safe in place "msm_dcvs" which resets the CPU to 918Mhz or 1026Mhz or 1512Mhz
could also be some other things i am still searching
now there are ways to circumvent these issues but given the risk of the damage associated with overclock for long time i think its in our best interest to not screw with these fail-safes...
Click to expand...
Click to collapse
if someone could plz explain how to totaly disable thermal control - it would be much appreciated.
if you totally disable them your Smartphone will shutdown every time you reach....(cant remember! think it was 75°C) SoC Temp! and you will reach that kinda fast!
i know that soc is an 8026 but how many core and which gpu are in that snapdragon on GWR? Because somesay that it have 2 core and adreno 220 and someone else say that it's a normal quadcore with adreno 305
You might want to check this thread:
http://forum.xda-developers.com/g-watch-r/orig-development/kernel-intersectravens-kernel-t2957728
It has all 4 cores, with max speed of 1.2GHz (I think?)
It comes with only 1 core enabled out of the box on the default kernel, but it's possible to enable all 4. The problem is of course battery life, and it makes a huge difference when you enable all 4 and start playing with the watch.
It also gets quite (uncomfortably) warm for example during the initial synchronization (when all the apps are installed/compiled by ART).
A good compromise is 2 cores limited to 800MHz, which is what I'm running right now (a default setting on the kernel I linked in recent versions) and I cannot complain. I think it now actually drains less power than stock (some optimizations were added) and it is a lot more responsive. There's no need for more power anyway.
Its any chance to make all 8 cores working?With root and some script will be possible?
They do under heavy loads. A57s pressure the battery so much and heat without cooling if work continuously. I heard A73s work continuously like A53s.
@Oveana cores got disabled on nougat and that's true!! We can't deny this!! Enabling 6 cores by default as in MM would be soo great or leaving a toggle to enable device performance to use 6 cores is a better idea which we CAn expect in future updates!!
Still no solution??
@Pwruser Its verry annoyng ,SONY DO THE WORST work ever and a fraud Maybe devs can modify kernel to make all cores to work
Get back to MM!! That's all u can do for now....Or flash a custom kernel If u r not on warranty!!!
Big cores work like mm
https://ibb.co/geGYiv
All cores are working with my Sony Z3+ with Nougat .376. By default, only 4 cores run with min frequency, other cores will start running only if there is load, it is for saving battery. You can check with "Kernel Editor" app (rooted only).
flash androplus kernel and enjoy 8cores!
@yxtl there's your answer,
also: having all 8 cores active on max performance lets the device run into thermal limit FAST,
thus ==> lots of throttling, performance goes down, lower than snapdragon 808,
do you REALLY want that ?
Just observe what the big cores do once you raise load on the device ...
And that changes things exactly how ?
Explain ?
Is there a difference in behavior of hotplug ?
(I'm curious)
Thx for answer I run some testes myself ,and A57 cores are not complete disabled ,just need more pressure to work,I asked to sony support and i got same answer
Moto Z2 Force is a blazing fast smartphone. This out of any doubt.
Fore sure it is the fastest phone I've ever worked on.
On the shelf a lot of phones seem to be fast, BUT when you install over 200 apps on them and you are using 7 home screens full of widgets (ehm...) things become "a bit" different...
Not this time: over 200 apps installed didn't change it's fantastic speed. It's like working on an iPhone.. BUT this *is* doing something too! :laugh:
What's more interesting is that... it can be even faster too!!!
Many smartphones can be sligtly overclocked because of heating and battery life needs that lead manufacturer to lock frequencies to lower values respect of SoC capabilities. BUT usually root isn't enough to have overclock access, since higher frequencies need a modified kernel to be unlocked..
But Moto Z2 Force is not "one of many" smartphones...
Motorola confirmed my first impression I had on my old Griffin (Moto Z): they are making smartphone for "geeks"!
Moto Z2 force is using an 8 core Snapdragon 835 using "big-LITTLE" architecture:
- 4 high performance Kyro 280 cores clocked between 345 and 2361 MHz (big)
- 4 low power Kyro (???) cores clocked between 672 and 1900 MHz (LITTLE)
(frequencies adopted on EU unbranded XT1789-06... on different markets/versions they could differ...)
Obviously, low power cores work most on screen off conditions and during light tasks, while high performance ones enter the game when more performances are required as we have already seen on many similar architectures...
What's particularly interesting is that 2361 MHz is NOT the higher frequency of Kyro 280 and 672 MHz is NOT the lower frequency low power Kyro can work before going to deep sleep condition...
In fact big cores can work up to 2457 MHz (in a single step) and LITTLE ones down to 300 MHz (with 300, 364, 441, 518, 595 MHz intermediate steps available!)
What's is even more interesting is that simply by having root and a (great!) app called Kernel Adiutor - available on Play Store too - we can go to change (temporary or permanently) these values to overclock and/or underclock our system, eventually having better performances and/or better battery lifes...
I'm testing this and results are confirmed (by Kernel Adiutor statistics too...) and interesting: Z2 Force is not a device prone to overheat (like was my old Griffin instead... ) and so it seems to work with no issues at all @2457 MHz with interesting Geekbench 4 results as attached (please note that results are taken with all my 200 apps still installed & working... on lighter conditions they could be quite better too...).
In any case they are better than any Android Device recorded to date in Geekbench 4 charts... expecially for Multi-Core results...!! :highfive:
Underclock LITTLE cores from 672 MHz to lower values could (and I underline could...) improve battery life expecially during screen off conditions, BUT there are considerations to be taken:
- lower frequencies involves more time out of "deep sleep" condition too...
- on many devices adopting very low frequencies often lead to slow (or difficulties in...) "screen back on" operations
BUT there are MANY frequencies to eventually test so... games are open!!!
In any case, Motorola again! :good:
Feedbacks and eventual Geekbench4 / Antutu results on different clock settings are the welcome...
This is with the pantheon Kernel, prior to poking it.
https://browser.geekbench.com/v4/cpu/4880631
I'm doing some little tune up experiments with frequencies and these are some first results:
- lowering lower working frequency of LITTLE cores up to 345 MHz (from 672 MHz) seems to create no issues or delays on powering on screen even using fingerprint sensor...
On the other hand I'm still not so sure of eventual power saving benefits (my Z2 setup is already very good during screen off time with an average consumption of about 1,5%/hr... so eventual differences are minimal)
- I've to doublecheck it (more confirms needed...) but I'm quite sure big cores are clocked at faster frequency (2.45 GHz) during boot up, then (when exactly?) lowered to a max frequency of 2.36 GHz... this seems to me simptom of a very well tuned up system...
Does somebody have voltages/frequencies tables for our phone?
enetec said:
I'm doing some little tune up experiments with frequencies and these are some first results:
- lowering lower working frequency of LITTLE cores up to 345 MHz (from 672 MHz) seems to create no issues or delays on powering on screen even using fingerprint sensor...
On the other hand I'm still not so sure of eventual power saving benefits (my Z2 setup is already very good during screen off time with an average consumption of about 1,5%/hr... so eventual differences are minimal)
- I've to doublecheck it (more confirms needed...) but I'm quite sure big cores are clocked at faster frequency (2.45 GHz) during boot up, then (when exactly?) lowered to a max frequency of 2.36 GHz... this seems to me simptom of a very well tuned up system...
Does somebody have voltages/frequencies tables for our phone?
Click to expand...
Click to collapse
They're in the kernel. I tried to do normal edits to lower and increase, but it did something weird and just parked them at 30mhz after compile...
Edit: https://github.com/Uzephi/kernel_nash/blob/upstream/arch/arm/boot/dts/qcom/msm8998-v2.dtsi
There is the link to the file that controls the frequencies for each bin of our phone
Uzephi said:
They're in the kernel. I tried to do normal edits to lower and increase, but it did something weird and just parked them at 30mhz after compile...
Edit: https://github.com/Uzephi/kernel_nash/blob/upstream/arch/arm/boot/dts/qcom/msm8998-v2.dtsi
There is the link to the file that controls the frequencies for each bin of our phone
Click to expand...
Click to collapse
Very complex!
I will take a deep look at this as soon as I would have a bit of time...
enetec said:
Very complex!
I will take a deep look at this as soon as I would have a bit of time...
Click to expand...
Click to collapse
Essentially, little CPU has one speed bin and frequencies available from 300-1900 and big CPU has 4 speed bins with frequencies from 300-2592. Top end changes depending on your bin. I.E. silicon lottery. Speed bin 0 can step higher than bin 3
Edit: to find speed bin, it's usually in proc/kmesg or proc/last_kmesg. Needs root to read
Uzephi said:
Essentially, little CPU has one speed bin and frequencies available from 300-1900 and big CPU has 4 speed bins with frequencies from 300-2592. Top end changes depending on your bin. I.E. silicon lottery. Speed bin 0 can step higher than bin 3
Click to expand...
Click to collapse
Yes, on my own device max available speed is 2457 MHz... but my doubt is, how a single device (using same software) would choose between different bins?
Anyway is voltage the complexity I was referring to... at first look It seems not using a fixed one for a single frequency as on my old LG G2 but a range... I've to look better at it...
Some first interesting results from tests have been achieved...
I will post a more detailed report in one day or two...
enetec said:
Yes, on my own device max available speed is 2457 MHz... but my doubt is, how a single device (using same software) would choose between different bins?
Anyway is voltage the complexity I was referring to... at first look It seems not using a fixed one for a single frequency as on my old LG G2 but a range... I've to look better at it...
Click to expand...
Click to collapse
It's quite simple. At boot the kernel reads all "devices" on the computer (our case, the phone) and runs checks at low level on the hardware for software revisions, serial numbers, Mac addresses and guess what? The speed bin embedded in the chip. It then runs a cmdline for the system to read the results to access the devices and use the kernel correctly. This is how I manipulated the system to read the bootloader as locked. On my kernel, go to developer options and you will see you can toggle bootloader unlocking. This is because the cmdline tells the system we are still locked.
Uzephi said:
It's quite simple. At boot the kernel reads all "devices" on the computer (our case, the phone) and runs checks at low level on the hardware for software revisions, serial numbers, Mac addresses and guess what? The speed bin embedded in the chip. It then runs a cmdline for the system to read the results to access the devices and use the kernel correctly. This is how I manipulated the system to read the bootloader as locked. On my kernel, go to developer options and you will see you can toggle bootloader unlocking. This is because the cmdline tells the system we are still locked.
Click to expand...
Click to collapse
Nice!
Anyway I saw official documentation of SD835 speaks about 2.45 GHz as max frequency... so other speed bins are for special/overclocked lots probably...
enetec said:
Nice!
Anyway I saw official documentation of SD835 speaks about 2.45 GHz as max frequency... so other speed bins are for special/overclocked lots probably...
Click to expand...
Click to collapse
Cherry-picking a commit by Flar2 on his Pixel 2 kernel that enables the 2.5Ghz on all bins. Hopefully it works.
Uzephi said:
Cherry-picking a commit by Flar2 on his Pixel 2 kernel that enables the 2.5Ghz on all bins. Hopefully it works.
Click to expand...
Click to collapse
Have you found (during you searches...) where is the routine which changes max frequency from 2.45 GHz to 2.36 GHz after boot?
enetec said:
Have you found (during you searches...) where is the routine which changes max frequency from 2.45 GHz to 2.36 GHz after boot?
Click to expand...
Click to collapse
Those are both different bins. Maybe it loads one then the other? In any event all bins will be 2.5 if this works. Building now
Edit: checking my device, I don't go down to 2.36, max on mine is 2.45
Uzephi said:
Those are both different bins. Maybe it loads one then the other? In any event all bins will be 2.5 if this works. Building now
Click to expand...
Click to collapse
Uhm... I'm not so sure this is bin related, since max frequency (2.45 GHz) still remains usable, but no more used after boot (it can be re-enabled by Kernel Adiutor anyway)... this is more a simple setting IMHO...
enetec said:
Uhm... I'm not so sure this is bin related, since max frequency (2.45 GHz) still remains usable, but no more used after boot (it can be re-enabled by Kernel Adiutor anyway)... this is more a simple setting IMHO...
Click to expand...
Click to collapse
That's your bin which is set at boot... My bin gives me 2.45 by default... I am not rooted and haven't made changes. See attached screenshot
Built and works... See screenshot. All I did was change kernel. No other settings done. Next it to try UV
Uzephi said:
That's your bin which is set at boot... My bin gives me 2.45 by default... I am not rooted and haven't made changes. See attached screenshot
Click to expand...
Click to collapse
Nope. Your app reports only min & max available frequencies but not the used ones... In fact, if you look at your screenshot, min frequency is reported to be 300 MHz for all CPUs, BUT if you look at your frequencies at the screenshot moment, they are respectively 672 MHz for LITTLE & 345 MHz for big cores, that are the really used as min frequencies as stock.
If you install Kernel Adiutor all will be clearer for you... it reports all this in better way...
Uzephi said:
Built and works... See screenshot. All I did was change kernel. No other settings done. Next it to try UV
Click to expand...
Click to collapse
It works for sure... because probably new frequencies are still not used... see my previous post.
Try it out then ?
Edit: be sure to flash twrp boot image, then kernel then root. SU and Magisk lose root when flashing our kernels right now and will pull backup kernel from backup boot image
Edit 2: if you also look at my "after" screen, the CPU was pegged at 2.0 and 2.5 respectively due to just booting up and loading assets.