[Q&A] [INFO] [v1.0 beta5] [07-01-2015] CPU Governor ZZMoove

ZaneZam said:

Hi Guys,

i thought it would be a good idea to put all the infos of the zzmoove governor around here together on one place
for better way to find it, to have a place to dump stuff for future versions and to give support for specific questions.
for now i just copied the allready existend posts here but will edit this further when i have more time

so lets start with the first
initial version:
ZZMoove Governor v0.1
(post from 18th December 2012, 10:27 PM)

Why that “zzmoove” governor and how it works:

I thought it were pretty cool to have one of my favorite governors back from the old SGS1-days on my actual device, so i decided to take the sources and give that a try on top of boeffla kernel. It worked well so this is now the result of that experiment.

More about the internals:
Basically this is the ported SGS1 version of the well known "smoove" governor from the good old midnight kernel from Michael Weingaertner (mialwe) with a modified CPU hotplug implementation of the ktoonservative governor from ktoonesz. The original implementation from ktoonesz worked well but I observed that on idle most of the time only one cpu was going to sleep. Well that was not enough for me so I made a modification to put the other cpu's also to sleep (except cpu0). That means that this governor uses more often only one cpu on idle and as a consequence of that it needs less energy. Depending on System load and governor settings all 4 cores will be instantly up again if it is needed.

In short:
So what you can expect now from this thingy is a battery-friendly behaving hotplug conservative governor which
uses a frequency lookup table for faster upscaling (so called "smooth scaling") So this is more a energy-safer than a performer.

Tuneables/Defaults:

Sampling Rate (default=2) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate

Sampling Down Factor (default=4) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/sampling_down_factor

Up Threshold (default=70) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold

Up Threshold Hotplug (default=68) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug

Down Threshold (default=52) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold

Down Threshold Hotplug (default=55) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug

Ignore Nice Load (default=0) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/ignore_nice_load

Freqency Step (default=5) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/freq_step

Smooth Up (default=75) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up

Links:
Midnight kernel
KT747 Kernel
Common Infos about Governors,I/O Schedulers etc.

Credits to:
mialwe for his smoove governor
ktoonesz for original hotplug implementation

ZZMoove Governor v0.3
(Post from 25th February 2013, 05:06 PM - "more improvements")

there are now many new possibilities to adjust the governor more precisely via sysfs!
Following new tuneables were introduced in this new version:

The so called "sleep" values which were hardcoded in previous version are now changed
to sysfs-tuneables:

The Smooth Scaling for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up_sleep
possible values from 1 to 100, default: 100

The up/down Threshold for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_sleep
possible Values from above "down_threshold_sleep" to 100, default: 90

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_sleep
possible Values from 11 to under "up_threshold_sleep", default: 44

The Sampling Rate for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate_sleep_multiplier
possible values 1 or 2, default: 2

The amound of cores which should run at "screen off":
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/hotplug_sleep
possible Values 0 = do not touch cores (the same behaving as in standard setting of zzmoove) 1, 2 or 3
the number of cores to run on screen off. btw. setting "4" doesn't exist as u can use "0" for that setting!

Beside of that you can now change the hotplug threshold per core independently (thx to gsw5700 for the inital idea!)
and turn cores off completely.

For that purpose following tuneables were introduced and are replacing
the old hotplug up/down threshold tuneables:

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug1
hotplug up threshold for core 1 - 0 = turn off core 1, possible range from "down_threshold" to 100, default: 68

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug2
hotplug up threshold for core 2 - 0 = turn off core 2, possible range from "down_threshold" to 100, default: 68

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug3
hotplug up threshold for core 3 - 0 = turn off core 3, possible range from "down_threshold" to 100, default: 68

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug1
hotplug down threshold for core 1 - possible range from 11 to under "up_threshold", default: 55

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug2
hotplug down threshold for core 2 - possible range from 11 to under "up_threshold", default: 55

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug3
hotplug down threshold for core 3 - possible range from 11 to unter "up_threshold", default: 55

Thanks to:
gsw5700 for the initial Idea "hotplug threshold per core".
brijmathew indirectly for the initial idea "just one core at screen off" (i think he did'nt meant exactly that in his post but hey he switched on the led in my head! *gg*)

ZZMoove Governor v0.4
(Post from 1st May 2013, 10:59 PM - "limits")

Changelog:

Frequency Limits:
First of all there is now a (by me so called) "soft" limit function for limiting frequencies at screen off but also at screen on if u wish. however i recommend to set the screen on limit always with the (if provided) max scaling functionality of the kernel as this is the better way of doing it and "works better" for following reasons: touchboost and wake up frequencies can go above that governor-soft-limit (mostly to 800/1000 mhz) because the governor has no control over these "events" and will be "bypassed" by cpufreq driver! nevertheless by setting this soft limit at screen off the use of frequencies higher than the given limit will be strongly reduced and therefore this will reduce power consumption at screen off. and that was the main intention - saving power if u do not use your phone!

For this function following new tuneables were indroduced to set in sysfs (/sys/devices/system/cpu/cpufreq/zzmoove/):
freq_limit_sleep: limit freqency at screen off (possible values 0 disable limit, 200000-1600000, default: 0)
freq_limit: limit freqency at screen on (possible values 0 disable limit, 200000-1600000, default: 0)

Fast Scaling:
As a second feature in this new version i added the so called (again by me *g*) "fast scaling" for faster up/down scaling! This should bring more performance but on the other hand this can be of course a little bit more power consumptive. try it, it makes things snappier and some people reported that with this setting touch boost can then also be disabled which wasn't really "possible" with previous versions of zzmoove governor.

For this function following new tuneables were indroduced to set in sysfs (/sys/devices/system/cpu/cpufreq/zzmoove/):
fast_scaling: fast scaling at screen on (possible values 0 disable or 1 enable, default: 0)
fast_scaling_sleep: fast scaling at screen off (possible values 0 disable or 1 enable, default: 0)

As last "feature" and to complete the "set" the tuneable "freq_step_sleep" was included to be able to change freq step only at screen off
possible settings are the same as the "freq_step" tuneable which are values from 0% (stops freq scaling) to 100% (switches frequencies from lowest to highest frequency and vice versa like ondmand governor) default is 1 in all settings (bat/opt/perf) at screen off.

ZZMoove Governor v0.5 aka "The Beast"
(performance and fixes)

Changelog:

- completely reworked fast scaling functionality. now using a "line jump" logic instead of fixed freq "colums".
fast scaling now in 4 steps and 2 modes possible (mode 1: only fast scaling up and mode2: fast scaling up/down)
- added support for "Dynamic Screen Frequency Scaling" (original implementation into zzmoove governor highly improved by Yank555)
originated by AndreiLux more info: http://xdaforums.com/showpost.php?p=38499071&postcount=3
- re-enabled broken conservative sampling down factor functionality ("down skip" method).
originated by Stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
- changed down threshold check to act like it should.
originated by Stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
- implemented/ported "early demand" from ondemand governor.
originated by Stratosk - more info: http://www.semaphore.gr/80-latests/98-ondemand-early-demand
- implemented/ported "sampling down momentum" from ondemand governor.
originated by Stratosk - more info: http://www.semaphore.gr/80-latests/80-sampling-down-momentum
- modified some original conservative code parts regarding frequency scaling which should work better now.
originated by DerTeufel1980: https://github.com/DerTeufel/androi...mmit/6bab622344c548be853db19adf28c3917896f0a0
- added the possibility to use sampling down momentum or conservative "down skip" method.
- increased possible max sampling rate sleep multiplier to 4 and sampling down factor to 100000
accordingly to sampling down momentum implementation.
- added frequency search limit for more efficient frequency searching in scaling "table" and for improving
frequency "hard" and "soft" limit handling.
- added cpu idle exit time handling like it is in lulzactive
again work from ktoonsez : https://github.com/ktoonsez/KT747-JB/commit/a5931bee6ea9e69f386a340229745da6f2443b78
description in lulzactive governor: https://github.com/ktoonsez/KT747-J...f2443b78/drivers/cpufreq/cpufreq_lulzactive.c
- fixed a little scaling step mistake and added overclocking frequencies up to 1800 mhz in scaling frequency "tables".
- fixed possible freezes during start/stop/reload of governor and frequency limit change.
- fixed hotplugging logic at online core 0+3 or 0+2 situations and improved hotplugging in general by
removing mutex locks and skipping hotplugging when it is not needed.
- added possibility to disable hotplugging (that's a debugging relict but i thought maybe someone will find that usefull so i didn't remove it)
- try to fix lags when coming from suspend if hotplug limitation at sleep was active by enabling all offline cores during resume.
- code cleaning and documentation.

for this functions following new tuneables were indroduced:

Early Demand:
early_demand -> switch to enable/disable early demand functionality (possible values 0 disable or 1 enable, default: 0)
grad_up_threshold -> scale up frequency if the load goes up in one step of grad up value (possible range from 11 to 100, default 50)
little example for understanding: when the load rises up in one big 50% step then the
frequency will be scaled up immediately instead of wating till up_threshold is reached.

Fast Scaling (improved):
Fast scaling has now 8 levels which at the same time have 2 modes included. Values from 1-4 equals to scaling jumps in the frequency table and uses the Fast Scaling up but normal scaling down mode. Values from 5-8 equals to 1-4 scaling jumps but uses the fast scaling up and fast scaling down mode.

Hotplugging switch:
disable_hotplug -> switch to enable/disable hotplugging (possible values are any value above 0 to disable hotplugging and 0 to
enable it, default 0)

Sampling Down Factor and Sampling Down Momentum:
Description: From the original author of ondemand_sampling_factor David Niemi:
"This improves performance by reducing the overhead of load evaluation and helping the CPU stay
at its top speed when truly busy, rather than shifting back and forth in speed."

And that "Sampling Down Momentum" function from stratosk does this dynamicly now!

sampling_down_max_momentum -> max sampling down factor which should be set by momentum (0 disable momentum, possible range from sampling_down_factor up to MAX_SAMPLING_DOWN_FACTOR, default 0 disabled)
sampling_down_momentum_sensitivity -> how fast the sampling down factor should be switched (possible values from 1 to 500, default 50)
sampling_down_factor -> depending on which mode is active the factor for sampling rate multiplier which influences the whole
sampling rate or the value for stock "down skip" functionality which influences only the down scaling
mechanism (possible values are from 1 to MAX_SMPLING_DOWN_FACTOR, default 1 disabled)

Original conservative "down skip" or "stock" method can be enabled by setting the momentum tuneable to 0. so if momentum is inactive there will be a fallback to the stock method. as the name "down skip" says this method works "slightly" different from the ondemand stock sampling down method (on which momentum was based on). It just skips the scaling down code for the given samples. if u want to completely disable the sampling down functionality u can achieve this by setting sampling down factor to 1. so concluded: setting sampling_down_momentum = 0 and sampling_down_factor = 1 will disable sampling down completely (that is also the governor default setting)

Dynamic Screen Frequency Scaling:
Dynamicly switches the screen frequency to 40hz or 60hz depending on cpu scaling and hotplug settings. For compiling and enabling this functionality u have to do some more modification to the kernel sources, please take a look at AndreiLux Perseus repository and there at following commit: https://github.com/AndreiLux/Perseus-S3/commit/3476799587d93189a091ba1db26a36603ee43519 After adding this patch u can enable the feature by setting "CPU_FREQ_LCD_FREQ_DFS=y" in your kernel config and if u want to check if it is really working at runtime u can also enable the accounting which AndreiLux added by setting LCD_FREQ_SWITCH_ACCOUNTING=y in the kernel config. If all goes well and u have the DFS up and running u can use following tuneables to do some screen magic: (thx to Yank555 for highly extend and improving this!)

lcdfreq_enable -> to enable/disable LCDFreq scaling (possible values 0 disable or 1 enable, default: 0)
lcdfreq_kick_in_down_delay -> the amount of samples to wait below the threshold frequency before entering low display frequency mode (40hz)
lcdfreq_kick_in_up_delay -> the amount of samples to wait over the threshold frequency before entering high display frequency mode (60hz)
lcdfreq_kick_in_freq -> the frequency threshold - below this cpu frequency the low display frequency will be active
lcdfreq_kick_in_cores -> the number of cores which should be online before switching will be active. (also useable in combination
with kickin_freq)

So this version is a kind of "featured by" release as i took (again *g*) some ideas and work from other projects and even some of that work
comes directly from other devs so i wanna thank and give credits:

First of all to stratosk for his great work "sampling down momentum" and "early demand" and for all the code fixes which found their way into
the upstream kernel version of conservative governor! congrats and props on that stratos, happy to see such a nice and talented dev directly
contibuting to the upstream kernel, that is a real enrichment for all of us!

Second to Yank555 for coming up with the idea and improving/completeing (leaves nothing to be desired now *g*) my first
rudimentary implementation of Dynamic Screen Frequency Scaling from AndreiLux (credits for the idea/work also to him at this point!).

Third to DerTeufel1980 for his first implementation of stratosk's early demand functionality into version 0.3 of zzmoove governor
(even though i had to modify the original implementation a "little bit" to get it working properly ) and for some code optimizations/fixes regarding scaling.

Last but not least again to ktoonsez - I "cherry picked" again some code parts of his ktoonservative governor which should improve this governor
too!

ZZMoove Governor 0.5.1a
(bugfixes)

urgend bugfix release:

- fix governor switching issues (deadlocks) which oviously werend fixed in version v0.5
- optimised scaling function a lot (thx and credits to Yank555!)

ZZMoove Governor 0.5.1b (in cooperation with Yank555)
(bugfixes and more optimisations)

Changelog:

- now really fixed the governor switching issues! (gotcha *****! *g*)
- again some changes in scaling logic from Yank555 (thx and credits)
- simplified some tuneables by using already available stuff instead of using redundant code (thx Yank555)
- reduced/optimised hotplug logic and preperation for automatic detection of available cores
(maybe this fixes also the scaling/core stuck problems)

ZZMoove Governor 0.6 (in cooperation with Yank555)
(flexibility)

Changelog:

- removed fixed scaling lookup tables and use the system frequency table instead
changed scaling logic accordingly for this modification (thx and credits to Yank555)
- reduced new hotplug logic loop to a minimum
- again try to fix stuck issues by using seperate hotplug functions out of dbs_check_cpu (credits to ktoonesz)
- added support for 2 and 8 core systems and added automatic detection of cores were it is needed
(for setting the different core modes you can use the macro 'MAX_CORES'. possible values are: 2,4 or 8, default are 4 cores)
reduced core threshold defaults to only one up/down default and use an array to hold all threshold values
- fixed some mistakes in "frequency tuneables" (Yank555):
stop looping once the frequency has been found
return invalid error if new frequency is not found in the frequency table

ZZMoove Governor 0.6a (in cooperation with Yank555)
(scaling logic flexibility)

Changelog:

- added check if CPU freq. table is in ascending or descending order and scale accordingly
(compatibility for systems with 'inverted' frequency table like it is on OMAP4 platform)
thanks and credits to Yank555!

ZZMoove Governor 0.7 aka "Tamed Beast" (in cooperation with Yank555)
(slow down)

Changelog:

- reindroduced the 'old way' of hotplugging and scaling in form of the 'Legacy Mode' (macros for enabling/disabling this done by Yank555, thx!)
NOTE: this mode can only handle 4 cores and a scaling max frequency up to 1800mhz.
- added hotplug idle threshold for a balanced load at CPU idle to reduce possible higher idle temperatures when running on just one core.
(inspired by @JustArchi observations, thx!)
- added hotplug block cycles to reduce possible hotplugging overhead (credits to @ktoonsez)
- added possibility to disable hotplugging only at suspend (inspired by a request of @STAticKY, thx for the idea)
- introduced hotplug frequency thresholds (credits to Yank555)
- hotplug tuneables handling optimized (credits to Yank555)
- added version information tuneable (credits to Yank555)

for this functions following new tuneables were indroduced:

legacy_mode -> for switching to the 'old' method of scaling/hotplugging. possible values 0 to disable, any values above 0 to enable (default is 0)
NOTE: the legacy mode has to be enabled by uncommenting the macro ENABLE_LEGACY_MODE
hotplug_idle_threshold -> amount of load under which hotplugging should be disabled at idle times (respectively at scaling minimum). possible values 0 disable, from 1 to 100 (default is 0)
hotplug_block_cycles -> slow down hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)
disable_hotplug_sleep -> same as disable_hotplug but will only take effect at suspend. possible values 0 disable, any values above 0 to enable (default is 0)
up_threshold_hotplug_freq1 -> hotplug up frequency threshold for core1. possible values 0 disable and range from over down_threshold_hotplug_freq1 to max scaling freqency (default is 0)
up_threshold_hotplug_freq2 -> hotplug up frequency threshold for core2. possible values 0 disable and range from over down_threshold_hotplug_freq2 to max scaling freqency (default is 0)
up_threshold_hotplug_freq3 -> hotplug up frequency threshold for core3. possible values 0 disable and range from over down_threshold_hotplug_freq3 to max scaling freqency (default is 0)
down_threshold_hotplug_freq1 -> hotplug down frequency threshold for core1. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq1 freqency (default is 0)
down_threshold_hotplug_freq2 -> hotplug down frequency threshold for core2. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq2 freqency (default is 0)
down_threshold_hotplug_freq3 -> hotplug down frequency threshold for core3. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq3 freqency (default is 0)
version -> show the version of zzmoove governor

ZZMoove Governor 0.7a
(little fix)

Changelog:

- fixed a glitch in hotplug freq threshold tuneables which prevented setting of values in hotplug down freq thresholds when hotplug
up freq thresholds were set to 0. NOTE: enabling the legacy mode in the source is not part of that fix i just forgot to set it back to standard (disabled) before pushing, sry to lazy to fix that fix now

ZZMoove Governor 0.7b
(compatibility improved and forgotten things)

Changelog:

- fixed stuck at max scaling frequency when using stock kernel sources with unmodified cpufreq driver and without any oc capabilities.
- readded forgotten frequency search optimisation in scaling logic (only effective when using governor soft frequency limit)
- readded forgotten minor optimisation in dbs_check_cpu function.
- as forgotten to switch in last version Legacy Mode now again disabled by default
- minor code format and comment fixes

ZZMoove Governor 0.7c
(again compatibility and optimisations)

Changelog:

- frequency search optimisation now fully compatible with ascending ordered system frequency tables (thx to @psndna88 for testing!)
- again minor optimisations at multiple points in dbs_check_cpu function
- code cleaning - removed some unnecessary things and whitespaces nuked - sry for the bigger diff but from now on it will be clean!
- corrected changelog for previous version regarding limits

ZZMoove Governor 0.7d (bugfix!)
(broken things)

Changelog:

- fixed hotplug up threshold tuneables to be able again to disable cores manually via sysfs by setting them to 0
- fixed the problem caused by a "wrong" tuneable apply order of non sticking values in hotplug down threshold tuneables when
hotplug up values are lower than down values during apply.
NOTE: due to this change right after start of the governor the full validation of given values to these tuneables is disabled till
all the tuneables were set for the first time. so if you set them for example with an init.d script or let them set automatically
with any tuning app be aware that there are illogical value combinations possible then which might not work properly!
simply be sure that all up values are higher than the down values and vice versa. after first set full validation checks are enabled
again and setting of values manually will be checked again.
- fixed a typo in hotplug threshold tuneable macros (would have been only a issue in 8-core mode)
- fixed unwanted disabling of cores when setting hotplug threshold tuneables to lowest or highest possible value
which would be a load of 100%/11% in up/down_hotplug_threshold and/or scaling frequency min/max in up/down_hotplug_threshold_freq

Click to expand...

Click to collapse

ilfat12 said:

Hi!
Where I can read is responsible for what in one way or another option?
Now I'm interested in the inputboost options.
What's the difference between inputboost_cycles and inputboost_punch_cycles?
What give these options: inputboost_punch_epenmove and inputboost_punch_fingermove?
Forgive me if I ask stupid questions))
Thanks!

Click to expand...

Click to collapse

Added native input booster to ZZMoove (based on faux123′s intelliactive)
I’ve added my own port of the native input booster from intelliactive into ZZMoove. Input events such as buttons, touchkeys, and the touchscreen will temporarily modify different ZZMoove settings. Using this allows for extremely conservative governor settings to be used without affecting performance. The boost is made up of two stages; the first is meant to be a very short high speed burst, just a few hundred milliseconds. The second stage is a reduced up threshold that is applied for the duration of the entire boost.

Click to expand...

Click to collapse

Henriquefeira said:

How do I enable deep sleep mode at zzmove? Because mine is not working

Click to expand...

Click to collapse

tuhinxp04 said:

Is this possible to make make yang battery extreme (3) profile set by default.....? Every time i set this but changed automatically zzrelax(11).....After unlock my phone....!

Click to expand...

Click to collapse

Solvin said:

Hi ZaneZam. I use your Governor with Boeffla Kernel Beta on my S5.

I use the optimized profile with following additional tunables:

Fast Scaling Sleep Up: 5
Fast Scaling Sleep Down: 5
Fast Scaling Up: 5
Fast Scaling Down: 5
Sampling Rate Sleep Multiplier: 2

I use apps like Facebook or Chrome and than the phone freezes and reboots. This happened 2 times every day.

I checked the Insane profile and that's very similar to the optimized with my tunables. Why it doesn't work?

Click to expand...

Click to collapse

ZaneZam said:

Yes it is possible either via a default value in the governor itself or maybe via the tool u use to switch it which u didn't reveal to us

i just can say that there is nothing included from my side which changes a profile "at sleep" so it must be something which is dealing with the tuneables automatically. I can imagine some kind of "at sleep changing settings" mode.

hm I don't have to ask if u are using uv/oc, don't I? maybe any chance of a crash log? the S5 seems still disliking zzmoove in some situations.

Click to expand...

Click to collapse

Solvin said:

I don't use UV, only OC but without OC it's the same. How can I create a crashlog?

Click to expand...

Click to collapse

Solvin said:

And it crashed again (reboot). I send you the crashlog via mail

Click to expand...

Click to collapse

ZaneZam said:

thx for the log, it rebooted yes but it didn't crash (at least the kernel did not!)

so in short: the log is clean, no kernel problem in my opinion but one thing: you have UV set to "custom" in boeffla config which means "the setting for custom values"
and which could still contain values u have changed previously (or have changed by a settings preset)! if u really want stock settings then choose "no undervolting"!
Lord boeffla recently changed the naming from "none" to "custom" upon the advice of me because i had one user which had a similar problem like u (i ask about uv because
of a reason, it's "smelling like that" *g*) and this user had previously tested values still active because he thought "none" is "off" so try to choose "no undervolting" then
u really have no uv values set.

hope this stabilizes things for u. otherwise feel free to get back with another log
:fingers-crossed:

Click to expand...

Click to collapse

thaibinh262 said:

Someone explain about profile? i read it many time but dont understand it.

Click to expand...

Click to collapse

nytebird said:

Can I get some help with my LG G3 zzmove profile 2 /5 settings? It runs good with the default settings, but I'd like to get some more performance and speed and get rid of the lag I have. SlimSaber 5.1.1 Nebula 12.0 using Kernel Adiutor

Click to expand...

Click to collapse