Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,736,443 Members 49,307 Now Online
XDA Developers Android and Mobile Development Forum

[KT747: Share & discuss your settings]+[govs & scheds info]

Tip us?
 
liltitiz
Old
(Last edited by liltitiz; 13th February 2013 at 08:51 AM.)
#1  
liltitiz's Avatar
Senior Member - OP
Thanks Meter 609
Posts: 988
Join Date: Aug 2012
Location: Québec
Default [KT747: Share & discuss your settings]+[govs & scheds info]


It looks like this thread is starting to be way more popular than i expected when I created it! I decided to add useful OP to it.


Here is a list of a few things to know about how I want this thread to be:

  • First of all, everybody is more than welcome to share settings, knowledge or any useful informations that could help someone. XDA is all about helping each other.
  • No Question is too stupid. Feel free to ask anything that is related to the kernel. I specified KT747 in the title because this is what I personally use but any adjustement made to governors, schedulers and undervolting will work with different kernels that allow you to adjust those settings. So even if you don't use KT747, you're welcome to post here.
  • Before posting in this thread, read the entire OP and second post with useful links and informations.
  • Finally, be respectful and have fun!


How to share settings:

- Begin by telling what is your rom, the date or name of the release, jellybean or ics, AOSP or touchwiz, 4.1.2 or 4.2.1 and also specify which release of KT747 you are using or if you are using another kernel.
- Let us know your general settings: Min/Max frequencies, screen off profile(Mhz and/or governor) and vibration strength.
- Then share with us what governor and I/O scheduler you are using and if you made any adjustements to them.
- If you share adjustements you made on governors or schedulers, you can take screenshots or just write which tunables you change and what values you assigned to it.
- If you share undervolting settings, to avoid huge post with a lot of screenshots,we will do it differently: If you substracted the same amount of mV to every steps, just say how much. If you tweaked every steps separetly, you can type each voltages or you just make sure you have a backup of your settings, go into /sdcard/KTweaker/, copy the lines coresponding to the voltages and share it this way:
Voltage(from 2106 to 96 MHz):
1250 1225 1200 1175 1150 1125 1100 1085 1065 1045 1025 1005 985 965 945 925 905 890 875 860 845 830 815 800 790 780 770 760 750 745.
- To share your KTweaker backup file (/sdcard/KTweaker/). Specify if it is set on boot or not and if it has custom voltages. If you have custom undervoltage setting you better make a backup that is not set on boot or set on boot after 30 seconds. So if some device doesn't take your undervolt values they won't be stock in a bootloop.



Finally, Thanks to Ktoonsez for his amazing kernel that you can find here: http://forum.xda-developers.com/show....php?t=1756776
You can Donate to Ktoonsez here: http://forum.xda-developers.com/dona....php?u=4325945
The Following 20 Users Say Thank You to liltitiz For This Useful Post: [ Click to Expand ]
 
liltitiz
Old
(Last edited by liltitiz; 27th March 2013 at 06:17 AM.)
#2  
liltitiz's Avatar
Senior Member - OP
Thanks Meter 609
Posts: 988
Join Date: Aug 2012
Location: Québec
Default Useful links and informations

Useful links and informations.


Informations about Governors:


The following infos were found here:
http://forum.xda-developers.com/show....php?t=1369817
http://forum.xda-developers.com/show...php?p=28647926
http://forum.xda-developers.com/show....php?t=1369817

Ondemand:
Default governor in almost all stock kernels. One main goal of the ondemand governor is to switch to max frequency as soon as there is a CPU activity detected to ensure the responsiveness of the system. Effectively, it uses the CPU busy time as the answer to "how critical is performance right now" question. So Ondemand jumps to maximum frequency when CPU is busy and decreases the frequency gradually when CPU is less loaded/apporaching idle. Even though many of us consider this a reliable governor, it falls short on battery saving and performance on default settings.

Conservative:
A slower Ondemand which scales up slowly to save battery. The conservative governor is based on the ondemand governor. It functions like the Ondemand governor by dynamically adjusting frequencies based on processor utilization. However, the conservative governor increases and decreases CPU speed more gradually. Simply put, this governor increases the frequency step by step on CPU load and jumps to lowest frequency on CPU idle. Conservative governor aims to dynamically adjust the CPU frequency to current utilization, without jumping to max frequency.

Interactive:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations.

Intellidemand:
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.

Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly.

Userspace:
Instead of automatically determining frequencies, lets user set frequencies.

Powersave:
Locks max frequency to min frequency. Can not be used as a screen-on or even screen-off (if scaling min frequency is too low).

Performance:
Sets min frequency as max frequency. Use this while benchmarking!

Scary:
A new governor wrote based on conservative with some smartass features

Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups.

Pegasusq:
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values ​​arranged.

MSM DCVS:
a very efficient and wide range of Dynamic Clock and Voltage Scaling (DCVS) which addresses usage models from active standby to mid and high level processing requirements.

Abyssplug governor:
It is a modified Hotplug Governor: The “hotplug” governor scales CPU frequency based on load, similar to “ondemand”. It scales up to the highest frequency when “up_threshold” is crossed and scales down one frequency at a time when “down_threshold” is crossed. Unlike those governors, target frequencies are determined by directly accessing the CPUfreq frequency table, instead of taking some percentage of maximum available frequency.

SLP governor:
It is a mix of pegasusq and ondemand


Governor tunables explanations


OnDemand, Conservative, Ktoonservative, Adaptive, Intellidemand:
sampling_rate:Measured in uS , this is how often the kernel look at the CPU usage and make decisions on what to do about the frequency. Higher values means CPU polls less often. For lower frequencies, this could be considered an advantage since it might not jump to next frequency very often, but for higher frequencies, the scale-down time will be increased.
up_threshold: Measured in percentage 1-100, When CPU load reaches this point, governor will scale CPU up. Higher value means less responsiveness and lower values corresponds to more responsiveness at the cost of battery.
powersave_bias: Default value is 0. Setting a higher value will bias the governor towards lower frequency steps. Use this if you want CPU to spend less time on higher frequencies. A better alternative would be to underclock to a lower frequency than using powersave bias.
sampling_down_factor: In the simplest form, sampling_down_factor determines how often CPU should stay at higher frequencies when truly busy. Default behavior is fast switching to lower frequencies (1). Having sampling_down_factor set to 1 makes no changes from existing behavior (for the non-modified ondemand), but having sampling_down_factor set to a value greater than 1 causes it to act as a multiplier for the scheduling interval for re-evaluating the load when the CPU is at its highest clock frequency (which is scaling_max_freq) due to high load. This improves performance by reducing the overhead of load evaluation and helping the CPU stay at its highest clock frequency when it is truly busy, rather than shifting back and forth in speed. This tunable has no effect on behavior at lower frequencies/lower CPU loads.
down_differential: This factor indirectly calculate the 'down-threshold' of Ondemand. After completing sampling-down-factor*sampling-rate at max frequency because of high load, governor samples the load again to calculate an estimate of the new target frequency in a way that the lowest frequency will be chosen that would not trigger up_threshold in the next sample. Because triggering up-threshold will again cause CPU to scale up to max frequency. During this choice down_differential is taken into account as a breathing room value. Target frequency is calculated as max_load_freq / (up_threshold - down_differential). The obtained value might be a non-existent value in the freq_table and CPU driver will round it off to a value in freq_table. max_load_freq is the theoretical frequency at which CPU can handle 100% workload. It is usually a value below scaling_max_freq. See this post by AndereiLux for more info.
freq_step: Whenever up-scaling logic is triggered the governor instructs the CPU to raise its frequency by freq_step percentage of max allowed frequency. (max policy * (freq step / 100)). Ex: max policy is 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, hence 336 becomes 400. So say we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz. Note that freq_step and smooth_scaling does pretty much the same thing.

SmartassV2 & AssWax
awake_ideal_freq: The frequency until which CPU is scaled up rapidly on screen-awake (from sleep). Thereafter, scaling up is less aggressive.
sleep_ideal_freq: The frequency until which CPU is scaled down rapidly when screen is turned off. Thereafter, scaling down is less aggressive.
up_rate_us: The minimum amount of time to spend at a frequency before we can ramp up. (Ignored below awake-ideal frequency since governor needs to rapidly scale up to awake_ideal_freq when below it)
down_rate_us: The minimum amount of time to spend at a frequency before we can ramp down. (Ignored above sleep-ideal frequency since governor needs to rapidly scale down to sleep_ideal_freq when above it)
max_cpu_load: Same as up_threshold in other governors.
min_cpu_load: Same as down_threshold in other governors.
ramp_down_step: Frequency delta when ramping down below the ideal frequency. Zero disables and will calculate ramp down according to load heuristic. When above the ideal frequency we always ramp down to the ideal freq.
ramp_up_step: Frequency when ramping up above the ideal frequency. Zero disables and causes to always jump straight to max frequency. When below the ideal frequency we always ramp up to the ideal freq.
sleep_wakeup_freq: The frequency to set when waking up from sleep. When sleep_ideal_freq=0 this will have no effect.

Interactive
hispeed_freq: Hi speed to bump to from lo speed when load burst. (Default value is scaling max freq)
go_hispeed_load: Go to hi speed when CPU load at or above this value. (Similar to Up-Threshold in other governors)
min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down. (Sounds like Lazy governor?!)
timer_rate:
The sample rate of the timer used to increase frequency.


PegasusQ:
cpu_up_rate: No of samples to evaluate load to scale CPU Up. After cpu_up_rate samples are finished for a frequency, CPU scale-Up logic is executed. In other words - before scaling Up, cpu_up_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
cpu_down_rate: No of samples to evaluate load to scale CPU Down. After CPU_down_rate samples are finished for a frequency, CPU scale-Down logic is executed. In other words - before scaling Down, cpu_down_rate*sampling_rate micro seconds are spend at a frequency.
UNIT: Positive Integer
hotplug_freq_1_1: Up threshold frequency to turn second core On, when some other conditions is also met. ie If (minimum frequency greater than or equal to hotplug_freq 1 1 and run queue length is greater than hotplug_rq_1_1) Hotplug IN Second Core. Higher value correpsonds to delay in turning on second core.
UNIT: Kilo Hertz
hotplug_freq_2_0: Down threshold frequency to turn second core Off, when some other conditions is also met. ie If (maximum frequency less than hotplug_freq 2 0 and run queue length is less than or equal to hotplug_rq_2_0) Hotplug OUT Second Core. Lower value correpsonds to delay in turning off second core.
UNIT: Kilo Hertz
hotplug_rq_1_1: Threshold run queue length for second core to turn on.
UNIT: Positive Integer
hotplug_rq_2_0: Threshold run queue length for second core to turn off.
UNIT: Positive Integer
freq_for_responsiveness: Until freq_for_responsiveness, Up Threshold considered for sampling load is up_threshold_at_min_freq. Also during the part where CPU is at maximum load frequency, governor need to find the optimal frequency as the next frequency - which should not trigger up_threshold in the next sampling. When such a frequency_next is found to be a) less than freq_for_responsiveness b) will not trigger down_threshold in the next sample, then the optimal frequency is set to freq_for_responsiveness.
up_threshold_at_min_freq: This threshold is used as up threshold while sampling at frequencies less than freq_for_responsiveness. Above that, normal up_threshold is used. This gives us an option to make scaling aggressive/relaxed until a frequency and normal for higher frequencies. Again, during calculation of optimal frequency which should not trigger up policy, down threshold to consider is difference between up_threshold_at_min_freq and down_differential
io_is_busy: Setting to 1 causes treating i/o wait time as CPU busy time. I/O busy is just an indication that CPU is performance critical, and system is not actually idle. IO wait time is excluded from the CPU idle time value is 1.
UNIT: Boolean 1 or 0
max_cpu_lock: If set to zero, hotplugs in and out second core when appropriate. Otherwise specifies no of cores to be considered for hotplugging. Leave it as default 0.
UNIT: Integer 0/1/2
hotplug_lock: Hotplugging second core is cancelled if it's value is greater than zero. The value should be greater than value of max_cpu_lock for a non-zero value. Leave it as 0.
UNIT: Integer 0/1/2
cpu_up_freq: Calculated as minimum of (its current value and maximum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
cpu_down_freq: Calculated as maximum of ( its current value and minimum frequency), this tunable is actually not used by the governor.
UNIT: Kilo Hertz
up_nr_cpus: Calculated as minimum of (its current value and num of possible cpus), this tunable is used by the governor to indirectly make Hotplugging decisions, but may not be useful for a 2 core CPU.
UNIT: Integer 1/2
dvfs_debug: Set to 1 to enable governor logging. If you're an enthusiast, this may be useful to view the impact of the values for governor tunable set by inspecting the log.
UNIT: Boolean 1 or 0

pegasusq.html"]http://www.androidiani.com/forum/modding-huawei-ascend-p1/280978-governor-pegasusq.html

Informations about I/O Schedulers


Noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.

CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

SIO
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

V(R)
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.

FIFO
It is an acronym for First In, First Out, which is an abstraction related to ways of organizing and manipulation of data relative to time and prioritization. This expression describes the principle of a queue processing technique or servicing conflicting demands by ordering process by first-come, first-served (FCFS) behaviour. FCFS is also the jargon term for the FIFO operating system scheduling algorithm, which gives every process CPU time in the order they come. Disk controllers can use the FIFO as a disk scheduling algorithm to determine the order to service disk I/O requests.

Zen
The zen I/O scheduler is basically based off of no-op with some exceptions. It uses deadlines, prioritizes synchronous requests over asynchronous requests, and does no sorting or merging.
It's similar to SIO, but closer to no-op, whereas SIO is closer to deadline without sorting or merging (on SIO, writes can starve read requests/writes are prioritized over writes, it uses its own former/latter_request functions where zen just uses the elevator ones). I think dispatching is also slightly different on SIO, everything on zen is just back-inserted closer to FCFS (but still not pure FCFS like FIFO).(Thanks to the member Bbedward on rootzwiki.com http://rootzwiki.com/topic/35781-ker.../page__st__750)

Row
The ROW scheduling algorithm will be used in mobile devices as default block layer IO scheduling algorithm. ROW stands for "READ Over WRITE" which is the main requests dispatch policy of this algorithm.
The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won’t have AS much parallel threads as on desktops. Usually it’s a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much.(Thanks to Tatyana Brokhman.http://comments.gmane.org/gmane.linu...s.arm.msm/2911)

I/O Schedulers tunables explanations


Deadline, SIO and Zen :
fifo_batch: This determines the number of reads or writes to issue in a single batch. The default is 16. Setting this to a higher value may result in better throughput, but will also increase latency.
front_merges: You can set this tunable to 0 if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting (1).
read_expire: This tunable allows you to set the number of milliseconds in which a read request should be serviced. By default, this is set to 500 ms (half a second).
write_expire: This tunable allows you to set the number of milliseconds in which a write request should be serviced. By default, this is set to 5000 ms (five seconds).
writes_starved: This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.
https://access.redhat.com/knowledge/...h06s04s02.html

CFQ
back_seek_max: Backward seeks are typically bad for performance, as they can incur greater delays in repositioning the heads than forward seeks do. However, CFQ will still perform them, if they are small enough. This tunable controls the maximum distance in KB the I/O scheduler will allow backward seeks. The default is 16 KB.
back_seek_penalty: Because of the inefficiency of backward seeks, a penalty is associated with each one. The penalty is a multiplier; for example, consider a disk head position at 1024KB. Assume there are two requests in the queue, one at 1008KB and another at 1040KB. The two requests are equidistant from the current head position. However, after applying the back seek penalty (default: 2), the request at the later position on disk is now twice as close as the earlier request. Thus, the head will move forward.
fifo_expire_async: This tunable controls how long an async (buffered write) request can go unserviced. After the expiration time (in milliseconds), a single starved async request will be moved to the dispatch list. The default is 250 ms.
fifo_expire_sync: This is the same as the fifo_expire_async tunable, for for synchronous (read and O_DIRECT write) requests. The default is 125 ms.
group_idle: When set, CFQ will idle on the last process issuing I/O in a cgroup. This should be set to 1 when using proportional weight I/O cgroups and setting slice_idle to 0 (typically done on fast storage).
group_isolation: If group isolation is enabled (set to 1), it provides a stronger isolation between groups at the expense of throughput. Generally speaking, if group isolation is disabled, fairness is provided for sequential workloads only. Enabling group isolation provides fairness for both sequential and random workloads. The default value is 0 (disabled). Refer to Documentation/cgroups/blkio-controller.txt for further information.
low_latency: When low latency is enabled (set to 1), CFQ attempts to provide a maximum wait time of 300 ms for each process issuing I/O on a device. This favors fairness over throughput. Disabling low latency (setting it to 0) ignores target latency, allowing each process in the system to get a full time slice. Low latency is enabled by default.
quantum: The quantum controls the number of I/Os that CFQ will send to the storage at a time, essentially limiting the device queue depth. By default, this is set to 8. The storage may support much deeper queue depths, but increasing quantum will also have a negative impact on latency, especially in the presence of large sequential write workloads.
slice_async: This tunable controls the time slice allotted to each process issuing asynchronous (buffered write) I/O. By default it is set to 40 ms.
slice_idle: This specifies how long CFQ should idle while waiting for further requests. The default value in Red Hat Enterprise Linux 6.1 and earlier is 8 ms. In Red Hat Enterprise Linux 6.2 and later, the default value is 0. The zero value improves the throughput of external RAID storage by removing all idling at the queue and service tree level. However, a zero value can degrade throughput on internal non-RAID storage, because it increases the overall number of seeks. For non-RAID storage, we recommend a slice_idle value that is greater than 0.
slice_sync: This tunable dictates the time slice allotted to a process issuing synchronous (read or direct write) I/O. The default is 100 ms.
https://access.redhat.com/knowledge/...html#id3044417

BFQ
timeout_sync, timeout_async: the maximum amount of disk time that can be given to a task once it has been selected for service, respectively for synchronous and asynchronous queues. It allows the user to specify a maximum slice length to put an upper bound to the latencies imposed by the scheduler.
max_budget: the maximum amount of service, measured in disk sectors, that can be provided to a queue once it is selected (of course within the limits of the above timeouts). According to what we said in the description of the algoritm, larger values increase the throughput for the single tasks and for the system, in proportion to the percentage of sequential requests issued. The price is increasing the maximum latency a request may incur in. The default value is 0, which enables auto-tuning: BFQ tries to estimate it as the maximum number of sectors that can be served during timeout_sync.
max_budget_async_rq: in addition to the max_budget, limit, async queues are served for a maximum number of requests, after that a new queue is selected.
low_latency: if equal to 1 (default value), interactive and soft real-time applications are privileged and experience a lower latency.
http://algo.ing.unimo.it/people/paol...escription.php


Row:
hp_read_quantum: dispatch quantum for the high priority READ queue
rp_read_quantum: dispatch quantum for the regular priority READ queue
hp_swrite_quantum: dispatch quantum for the high priority Synchronous WRITE queue
rp_swrite_quantum: dispatch quantum for the regular priority Synchronous WRITE queue
rp_write_quantum: dispatch quantum for the regular priority WRITE queue
lp_read_quantum: dispatch quantum for the low priority READ queue
lp_swrite_quantum: dispatch quantum for the low priority Synchronous WRITE queue
read_idle: how long to idle on read queue in Msec (in case idling is enabled on that queue).
read_idle_freq: frequency of inserting READ requests that will trigger idling. This is the time in Msec between inserting two READ requests

(http://lwn.net/Articles/509829/)
The Following 12 Users Say Thank You to liltitiz For This Useful Post: [ Click to Expand ]
 
TBayTom
Old
(Last edited by TBayTom; 14th September 2012 at 03:08 PM.)
#3  
TBayTom's Avatar
Senior Member
Thanks Meter 113
Posts: 532
Join Date: Mar 2011
Location: Orlando
With 4G LTE running most of the day...







Ondemand/bfq
Oc 1674 min 384
Touch Boosters 1242 & 918
Screen Off 384
Voltages lowered 50 or 100 across the board

ARIEL 2.07 ICS rom

Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
The Following User Says Thank You to TBayTom For This Useful Post: [ Click to Expand ]
 
liltitiz
Old
#4  
liltitiz's Avatar
Senior Member - OP
Thanks Meter 609
Posts: 988
Join Date: Aug 2012
Location: Québec
Have you tried ktoonservative?

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 
liltitiz
Old
#5  
liltitiz's Avatar
Senior Member - OP
Thanks Meter 609
Posts: 988
Join Date: Aug 2012
Location: Québec
How many minutes of asphalt 7?

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
 
TBayTom
Old
#6  
TBayTom's Avatar
Senior Member
Thanks Meter 113
Posts: 532
Join Date: Mar 2011
Location: Orlando
Quote:
Originally Posted by liltitiz View Post
Have you tried ktoonservative?

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!
Yes, I tried ktoonservative and noop at first, but for some reason it was draining my battery pretty fast (probably 8hr battery life). That was the 9-5 build, maybe my phone just doesn't like those settings, I'm not sure.


Quote:
Originally Posted by liltitiz View Post
How many minutes of asphalt 7?
About 20 mins of Asphalt 7
 
Heisenberg420
Old
#7  
Heisenberg420's Avatar
Senior Member
Thanks Meter 386
Posts: 1,401
Join Date: Apr 2011
Do you guys really see a difference in battery life by setting your screen off profile to 384-486? That just means a longer time to idle and 1/5th the clock cycles at 800mv vs 1080mv?
The Following User Says Thank You to Heisenberg420 For This Useful Post: [ Click to Expand ]
 
corythug
Old
#8  
corythug's Avatar
Senior Member
Thanks Meter 208
Posts: 1,587
Join Date: Aug 2011
Location: PA
I have my screen off at 810mhz, although I have 810mhz uv to 800mv so going any lower is a waste

Sent from my SGH-I747 using Tapatalk 2
 
thuglifesk
Old
#9  
thuglifesk's Avatar
Senior Member
Thanks Meter 59
Posts: 485
Join Date: Aug 2007
Location: Toronto
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?
 
liltitiz
Old
#10  
liltitiz's Avatar
Senior Member - OP
Thanks Meter 609
Posts: 988
Join Date: Aug 2012
Location: Québec
Quote:
Originally Posted by thuglifesk View Post
quick questions geniouses....for someone who doesnt know much about this kernel tweaking and uses their device moderately for phone, texting, facebook and music, what is the best setting you guys would recommend?
Sio schedulor with Pegasusq governor and try some under voting. Screen off profile around 486. Drop the vibration strength.

Sent from my SAMSUNG-SGH-I747 AOKP + KT747, 96-2106 MHz, noop, ktoonservative, undervolted, 3150mAh battery.
Thanks to: Ktoonsez, Task650 and Cyanogen for their amazing works!

The Following 3 Users Say Thank You to liltitiz For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes