Search This thread

stesmi

Senior Member
Jan 12, 2012
84
18
Stockholm
my phone could run 1.5 with #17 but in antutu it produced way lower scores (~4500) than on 1.35 (~6500). how does this thermal throttling actually work? if cpu reaches a given temperature it is throttled back to what? and what is this temperature?

my question is if it is any worth to run on 1.5 if it cannot stand it for long. in everyday use both 1.35 and 1.5 seem to be smooth but 'faster' is something always worth to experiment for :)

I only run 1.35 and I have been for quite a while now but after 20-40 seconds of heavy use (benchmarking for instance) it starts throttling until temperature drops under some threshold, and it'll keep dropping the speed all the way down to min if temp doesn't recover quickly, then when it's below it'll push itself back up to max and then throttle down again. Rinse and repeat. What the threshold is I do not know, nor do I know if it's the same temp sensor as we can use using a monitor app or StabilityTest. The reason I say that is because the temp shown in StabilityTest (and other apps) is (in my eyes) too low for throttling to happen and it's not consistent which temp it throttles at. Sometimes I can see 40 degrees C without throttling and sometimes I can't hit 33C without throttling. It feels like it's some other temp sensor that determines when to throttle.

// Stefan

---------- Post added at 12:27 PM ---------- Previous post was at 12:16 PM ----------

That's not very helpful Franco lol! Not using 1.5 is avoiding the problem.

It's not really though.

The phone is specced to run at 1.2GHz and anything above is gravy.

The CPU is already overclocked from factory.

I know, many of you are thinking "what is this guy smoking and can I have some?!" but it's true.

The CPU is specced to run at 1.5GHz yes, but that's with DCC enabled. Tech sheet says you have to use DCC above 1.0GHz. Our phones are run without DCC due to a hardware bug in the CPU. (I think it was the CPU).

The bug manifests itself in several ways :

Some CPUs don't run with DCC at all.
Some CPUs crash when switching between DCC and non-DCC.

And the same sheet says that you cannot use DCC below a certain frequency for the same reason.

What's this DCC thing I'm talking about:

There is a clock generator in the phone. I'm not totally sure but I think it's specced at 2.4GHz. Without DCC the frequency is halved (2.4 => 1.2GHz). With DCC the frequency is run natively.

The spec sheet says that at speeds up to 1.0GHz you run with DCC off (2.0GHz => 1.0GHz) and then turn it on and slow the speed down, say for example 1.2GHz for 1.2GHz operation and 1.5GHz for 1.5GHz operation. This keeps us within spec of the clock generator.

This is what our phones (some of the phones anyway) cannot do. Either it crashes enabling DCC or it crashes flipping DCC on/off.

// Stefan
 
Last edited:

atsavlis

Senior Member
Aug 4, 2009
458
37
Athens
Samsung Galaxy S10+
I was using morfics kernel at 1.5ghz with only a minor bump up in voltage. With franco17.2 I'm still unstable at 1.5ghz even at a much higher voltage (I don't wanna go past 1500mv)

Sent from my Galaxy Nexus using xda premium

Your phone obviously cant handle 1.5...
Im running v17.2 slightly undervolted, and have had no issues at all.. Im set at gazelle 350-1500
 

poopooface

Senior Member
Jan 20, 2012
77
6
I pushed 17.2 right after wiping and restoring my phone (thought it was bricked for a little bit due to a bug with the power button not working lol, but I figured it out). All seems smooth now, and 1.5 does work. However, there are occasional moments of lag and my AnPooPoo scores are pretty low, hovering around the low-high 4000's range.
 

marc.tulley

Senior Member
Jul 16, 2010
135
8
London
It's not really though.

The phone is specced to run at 1.2GHz and anything above is gravy.

The CPU is already overclocked from factory.

I know, many of you are thinking "what is this guy smoking and can I have some?!" but it's true.

The CPU is specced to run at 1.5GHz yes, but that's with DCC enabled. Tech sheet says you have to use DCC above 1.0GHz. Our phones are run without DCC due to a hardware bug in the CPU. (I think it was the CPU).

The bug manifests itself in several ways :

Some CPUs don't run with DCC at all.
Some CPUs crash when switching between DCC and non-DCC.

And the same sheet says that you cannot use DCC below a certain frequency for the same reason.

What's this DCC thing I'm talking about:

There is a clock generator in the phone. I'm not totally sure but I think it's specced at 2.4GHz. Without DCC the frequency is halved (2.4 => 1.2GHz). With DCC the frequency is run natively.

The spec sheet says that at speeds up to 1.0GHz you run with DCC off (2.0GHz => 1.0GHz) and then turn it on and slow the speed down, say for example 1.2GHz for 1.2GHz operation and 1.5GHz for 1.5GHz operation. This keeps us within spec of the clock generator.

This is what our phones (some of the phones anyway) cannot do. Either it crashes enabling DCC or it crashes flipping DCC on/off.

// Stefan

You dont have to be smoking anything to realise the stock speed is 1.2Ghz...

And I agree, above this is gravy but if I can go from Tesco Value Beef Gravy Garanules Gravy to Proper Beek fatty Juices Gravy then I'm happier still!

If you read my entire post you may understand that I just want to achieve the highest clock comfortabley possible. With or without DCC, I honestly dont mind as long as its stable. I understand the DCC definition but its irrelevant if some guys are fully happy and stable with or without it active.

So whether its with a few more kernel tweaks, some user voltage tweaks or a slight clock reduction I'd appreciate it as the OC junkie that I am.
 
Last edited:

Elganja

Senior Member
Jun 30, 2010
255
24
What exactly is SQlite? What exactly is this device IO that it's speeding up? I'm not sure of the terminology. I usually have francoturtle with hotplug on to give me the best battery life. Will this improve it also? What about turn logger off? What does that do? I checked it because it said it could save battery.

Sent from my Galaxy Nexus using Tapatalk

anyone figure out the answer to this? I just enabled it along with disabling logs.... hope it doesn't mess anything up!

on another note... 17.2 has been working well for me. No random reboots after an hour of random usage (17 would have crashed within 5min).



---------- Post added at 08:24 AM ---------- Previous post was at 07:58 AM ----------

Franco answered on google plus:

Francisco Franco - It's just to defrag the Sqlite files within Android.
me - so it can't, or shouldn't, hurt anything then right?
Francisco Franco - Yes, it won't do harm at all.

just wanted to pass the message along
 
Last edited:
  • Like
Reactions: yyz71

stesmi

Senior Member
Jan 12, 2012
84
18
Stockholm
What is throttling I see its a on going issue

Sent from my Galaxy Nexus using xda premium

Example:

You tell your phone to run 1.35GHz minimum and 1.35GHz maximum.

That way your phone shouldn't ever run at anything but 1.35GHz.

But you notice that that CPU clock goes below 1.35GHz at times. That is throttling.

Some/many phones run too hot under load, even sometimes at stock 1.2GHz speed.

They then lower the speed until the temps go down to a more reasonable temperature. When it lowers the phone increases the speed up back to whatever it's told to run at.

This is an abnormal condition, ie it does it to save itself from burning up.

Lowering the speed because the load is lower is a normal condition and not what we discuss here.

// Stefan
 

ratson

Inactive Recognized Developer
Nov 2, 2009
481
55
andrs.w3pla.net
OnePlus 11
I am sure the temp which is reported comes from the battery, cpus are usually fine till 70-80C.

I only run 1.35 and I have been for quite a while now but after 20-40 seconds of heavy use (benchmarking for instance) it starts throttling until temperature drops under some threshold, and it'll keep dropping the speed all the way down to min if temp doesn't recover quickly, then when it's below it'll push itself back up to max and then throttle down again. Rinse and repeat. What the threshold is I do not know, nor do I know if it's the same temp sensor as we can use using a monitor app or StabilityTest. The reason I say that is because the temp shown in StabilityTest (and other apps) is (in my eyes) too low for throttling to happen and it's not consistent which temp it throttles at. Sometimes I can see 40 degrees C without throttling and sometimes I can't hit 33C without throttling. It feels like it's some other temp sensor that determines when to throttle.

// Stefan

---------- Post added at 12:27 PM ---------- Previous post was at 12:16 PM ----------



It's not really though.

The phone is specced to run at 1.2GHz and anything above is gravy.

The CPU is already overclocked from factory.

I know, many of you are thinking "what is this guy smoking and can I have some?!" but it's true.

The CPU is specced to run at 1.5GHz yes, but that's with DCC enabled. Tech sheet says you have to use DCC above 1.0GHz. Our phones are run without DCC due to a hardware bug in the CPU. (I think it was the CPU).

The bug manifests itself in several ways :

Some CPUs don't run with DCC at all.
Some CPUs crash when switching between DCC and non-DCC.

And the same sheet says that you cannot use DCC below a certain frequency for the same reason.

What's this DCC thing I'm talking about:

There is a clock generator in the phone. I'm not totally sure but I think it's specced at 2.4GHz. Without DCC the frequency is halved (2.4 => 1.2GHz). With DCC the frequency is run natively.

The spec sheet says that at speeds up to 1.0GHz you run with DCC off (2.0GHz => 1.0GHz) and then turn it on and slow the speed down, say for example 1.2GHz for 1.2GHz operation and 1.5GHz for 1.5GHz operation. This keeps us within spec of the clock generator.

This is what our phones (some of the phones anyway) cannot do. Either it crashes enabling DCC or it crashes flipping DCC on/off.

// Stefan
 

franciscofranco

Recognized Developer
Dec 9, 2010
24,724
136,402
Carcavelos
You dont have to be smoking anything to realise the stock speed is 1.2Ghz...

And I agree, above this is gravy but if I can go from Tesco Value Beef Gravy Garanules Gravy to Proper Beek fatty Juices Gravy then I'm happier still!

If you read my entire post you may understand that I just want to achieve the highest clock comfortabley possible. With or without DCC, I honestly dont mind as long as its stable. I understand the DCC definition but its irrelevant if some guys are fully happy and stable with or without it active.

So whether its with a few more kernel tweaks, some user voltage tweaks or a slight clock reduction I'd appreciate it as the OC junkie that I am.

XDA's spirit is not "install X and Y to get your device over 9000 and doesn't matter how we got there, as long as it works". He gave you a perfect and technical explanation about this scenario so everything has been said.
 

JcMalta

Senior Member
Nov 23, 2011
77
37
Ilminster
The Best Kernel

FFS ... why do all these complaints come from people that want to over-clock or under-volt?

Franco's kernel at stock IS THE BEST .. my phone runs so smooth with no ****ing around with OC/UV ... WHY do you people think they can do better than the recommendations from a true expert? --- then come whining here when it doesn't work?

BTW ... my phone is **** at 1.5 too .... but do I actually care? I still have the best phone experience ever -- even on Turtle.
 

Bram77

Senior Member
Nov 25, 2007
412
74
Google Pixel 7 Pro
My Phone was working fine with 1.5Ghz using #17, but it's unstable using #17.2. I'll go back to #17 so I can use 200/1500 which was perfect and noticeably faster the 400/1350. Haven't had any stability issues with #17.
 
Last edited:

loudaccord

Senior Member
Aug 12, 2010
490
34
I'm still on #17 and overnight, this is the first time I've been able to get 1% drain per hour. I'm on Gazelle 400/1200 and haven't changed the UV settings. My personal recap of 17 is that this is the only way I can run over 1.35ghz without it slowing down and I can get good battery life. Win.
 

magn2o

Senior Member
Nov 30, 2011
600
256
So I've been using #17 without issue since around 4PM yesterday. Clocks are 700/1500, francoGazelle @ stock voltage. Absolutely no isssue, in fact, my phone has never been snappier. Battery life doesn't appear to have suffered, it's about on par with what it's been for the past few revisions.

I'm not sure what you did, franco -- but keep it up! I'll be avoiding any future releases with DCC re-enabled until you have a forked branch or toggle. :)

* Edit: I've attached #17 to this post, as a few people have asked me for it via PM.
 

Attachments

  • 3.0.21-franco.Kernel-nightly-17.zip
    4 MB · Views: 69
Last edited:

hnx6310

Member
Dec 20, 2011
34
1
4f76d735-c02a-9127.jpg
4f76d735-c035-36ce.jpg

.....:thumbdown::banghead:
Sent from my Galaxy Nexus using Tapatalk
 

refaa

Senior Member
Oct 29, 2009
265
14
So I've been using #17 without issue since around 4PM yesterday. Clocks are 700/1500, francoGazelle @ stock voltage. Absolutely no isssue, in fact, my phone has never been snappier. Battery life doesn't appear to have suffered, it's about on par with what it's been for the past few revisions.

I'm not sure what you did, franco -- but keep it up! I'll be avoiding any future releases with DCC re-enabled until you have a forked branch or toggle. :)

* Edit: I've attached #17 to this post, as a few people have asked me for it via PM.

what do u mean by 700/1500???

Mine is 350 mhz 1500??



Sent from my Galaxy Nexus using xda premium
 

atsavlis

Senior Member
Aug 4, 2009
458
37
Athens
Samsung Galaxy S10+
.....:thumbdown::banghead:
Sent from my Galaxy Nexus using Tapatalk

If you have a fever, can you go out and play a full hour of sport?? Same goes with our phones, cpu temperature goes up, cpu speeds get dropped, regardless of our setting, so that we dont fry our devices.

If people want to avoid temperature throttling, run your benchmaks with the phone in the freezer... :p lol
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1562
    I hate big OPs.

    Works on all roms. r390 and newer versions are ONLY for 4.3 or newer.

    F.A.Q:
    1. My device rebooted or crashed, how can I help?
    A: Get me /proc/last_kmsg on pastie.org.
    2. Battery sucks, my device is not entering deep sleep. FIX PLOX!
    A: Fix it yourself, it's an app waking your device up not the kernel's problem
    3. Signal is dropping since I flashed the kernel, amg u sucks!
    A: The kernel has nothing to do with gsm/cmda signal. Make sure you have the latest radios
    4. Do I need to wipe anything when flashing this kernel?
    A: No.
    5. Does this kernel has X or Y mod?
    A: Learn to read, everything you need to know is in the features list, changelog or public repo.

    Downloads:
    4.3: http://192.241.177.15/GalaxyNexus/4.3/
    4.4: http://192.241.177.15/GalaxyNexus/4.4/

    Kernel changelog:
    http://192.241.177.15/GalaxyNexus/4.3/appfiles/changelog.xml

    Source:
    https://github.com/franciscofranco/Tuna_JB_pre1/tree/nightlies-4.3

    franco.Kernel updater Free apk: http://xdaforums.com/showthread.php?t=1867127

    203
    [KERNEL][GPL][5 JUN - #Milestone 4][r200-ICS r210-JB] franco.Kernel | 4.0.3/4 |

    Terminal commands for all the options in this kernel:

    Color Multipliers:

    echo r g b > /sys/class/misc/colorcontrol/multiplier

    Replace r g and b for 2000000000 for stock color. If you want to change the colors just replace the first 3 numbers of each r/g/b with 0-400 of your choice.

    Gamma Control:

    echo r g b > /sys/class/misc/colorcontrol/v1_offset

    Replace r/g/b by -255/200 of your choice.

    Fsync:

    echo 1 > /sys/module/sync/parameters/fsync_enabled - to enable

    echo 0 > /sys/module/sync/parameters/fsync_enabled - to disable

    Sound Control:

    echo i > /sys/devices/virtual/misc/soundcontrol/volume_boost

    Replace i with 0-3 of your choice.

    Sound High Performance:

    echo 1 > /sys/devices/virtual/misc/soundcontrol/highperf_enabled - to enable

    echo 0 > /sys/devices/virtual/misc/soundcontrol/highperf_enabled - to disable

    USB Fast Charge:

    echo 1 > /sys/kernel/fast_charge/force_fast_charge - to enable

    echo 0 > /sys/kernel/fast_charge/force_fast_charge - to disable

    wifi_pm:

    echo 1 > /sys/module/bcmdhd/parameters/wifi_pm - to enable

    echo 0 > /sys/module/bcmdhd/parameters/wifi_pm - to disable

    Trinity's Contrast:

    echo i > /sys/module/panel_s6e8aa0/parameters/contrast

    Replace i with -25/16 of your choice.

    BLX:

    echo i > /sys/class/misc/batterylifeextender/charging_limit

    Replace i with 0-100 of your choice.

    OMAP Gamma interface:

    echo i > /sys/devices/platform/omapdss/manager0/gamma

    Replace i with 5-10 of your choice.

    Thermal Throttle:

    echo 1 > /sys/module/omap_temp_sensor/parameters/throttle_enabled - to enable

    echo 0 > /sys/module/omap_temp_sensor/parameters/throttle_enabled - to disable

    TCP Congestion Algorithm interface

    To check all the available options:

    sysctl net.ipv4.tcp_available_congestion_control

    To change to other option:

    sysctl -w net.ipv4.tcp_congestion_control=NAME_OF_THE_ALGORITHM

    Detailed test of all the algorithms:
    Latency - Download - Upload

    cubic:
    1st run: 15ms - 10,75Mbps - 7,82Mbps
    2nd run: 14ms - 10,84Mbps - 8,06Mbps

    reno:
    1st run: 13ms - 15,51Mbps - 6,73Mbps
    2nd run: 13ms - 14,73Mbps - 8,51Mbps

    bic:
    1st run: 12ms - 10,38Mbps - 8,61Mbps
    2nd run: 13ms - 10,78Mbps - 8,62Mbps

    westwood:
    1st run: 11ms - 17,65Mbps - 8,30Mbps
    2nd run: 13ms - 13,28Mbps - 8,29Mbps

    highspeed:
    1st run: 13ms - 10,76Mbps - 7,94Mbps
    2nd run: 16ms - 14,42Mbps - 8,52Mbps

    hybla:
    1st run: 14ms - 11,19Mbps - 7,44Mbps
    2nd run: 14ms - 13,47Mbps - 7,56Mbps

    htcp:
    1st run: 14ms - 13,24Mbps - 7,03Mbps
    2nd run: 15ms - 10,85Mbps - 8,00Mbps

    vegas:
    1st run: 14ms - 8,49Mbps - 6,62Mbps
    2nd run: 14ms - 12,00Mbps - 7,07Mbps

    veno:
    1st run: 13ms - 9,58Mbps - 8,13Mbps
    2nd run: 13ms - 8,50Mbps - 7,64Mbps

    scalable:
    1st run: 18ms - 12,01Mbps - 8,73Mbps
    2nd run: 14ms - 13,96Mbps - 8,23Mbps

    lp:
    1st run: 14ms - 14,90Mbps - 8,68Mbps
    2nd run: 14ms - 13,44Mbps - 8,72Mbps

    yeah:
    1st run: 14ms - 13,37Mbps - 8,28Mbps
    2nd run: 17ms - 13,89Mbps - 8,14Mbps

    illinois:
    1st run: 13ms - 12,93Mbps - 8,24Mbps
    2nd run: 16ms - 13,97Mbps - 6,46Mbps
    167
    Just woken up and feel like my head is going to explode already this last 5 pages is crazy

    haha. It's been a crazy two days. :) But it's been a blast.

    Now, sleep is over, time to get back to work!

    I got these from that thread:

    so it makes much sense, to make the min_sample_time as low as possible (?), but how low? what's the most appropriate sample time for battery and performance?

    for the timer_rate, franco suggested 30k to consider the CPUs latency. What has it to do with the cpu's latency?

    he also said min_sample_time doesn't have to be in multiple of timer_rate.
    in my case, all my timers are in 20k, which works fine as of now. But i must be missing some things, because I just saw somebody post these values, and no detailed explanation for having them.

    Yes and no. Here's what we're thinkin' so far.

    THIS POST WILL BE A RECAP OF THE LAST FEW PAGES OF RESEARCH! :)

    This was my original settings that I've been using for weeks:
    above_hispeed_delay: 20000
    go_hispeed_load: 50
    min_sample_time: 40000
    timer_rate: 20000
    So to make the short hand easier, we kept it in that order and just said: 20000/50/40000/20000 became 20k/50/40k/20k became 2/5/4/2. Make sense?

    Here is a breakdown of what they each mean:
    -above_hispeed_delay: Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load.
    -go_hispeed_load: The CPU load at which to ramp to the intermediate "hi speed".
    -min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down.
    -timer_rate: Sample rate for reevaluating cpu load when the system is not idle.

    This is a good explanation that I wrote back on page 3038:
    -above_hispeed_delay: higher = better battery, lower = better performance. (100k is default)
    -go_hispeed_load:.......higher = better battery, lower = better performance. (50 is default)
    -min_sample_time:......lower = better battery, higher = better performance. (60k is default)
    -timer_rate:.................higher = better battery, lower = better performance. (20k is default)
    So Google's default is 10/5/6/2. Lower numbers are all better for performance except min_sample_time (there higher is faster). So our goal is to find a sweet spot.

    The default 10 is for "Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load." So we think 10 is too high, but if you go too low, then you'll be using the higher freqs a lot more than you need and it will hurt the battery. So we are leaning towards 6 (60000) for above_hispeed_delay.

    The default 5 is for "when the CPU hits X% amount of load, then jump to the hispeed_freq." Again if this one is too low then it will cause the higher freqs to be used more often then they need, so we actually turn go_hispeed_load up a little bit to 7 (70).

    The default 6 is for "how long do I wait before lowering the clock speed from what it's currently at." So the lower we put this, the better battery will be. We're still trying to decide between 3 (30000) and 5 (50000). Osm0sis is getting more lag at lower levels, and finds the best performance mark at 5. So we turn min_sample_time down a little from stock to help with the battery.

    The default 2 is for "wait this long before changing the clockspeeds from what it's at now." While technically 2 sounds better because it's changing more often, Franco believes that by setting the timer_rate to be the same thing as the CPU sample_rate (which is preset at 30000), then that will make the CPU more efficient at switching. So we increased it from 2 (20000) to 3 (30000).

    So TO RECAP: Using the stuff from above, Google's defaults for these settings are 10/5/6/2 and we are changing them to 6/7/3/3 or 6/7/5/3 (again, still testing that third number for the min_sample_time).

    Does that make sense for everyone interested in following along? Any questions? Feel free to try out these settings yourself (the easiest way is with Franco's app or something like Trickster). We want as much feedback as possible on this.
    The next kernel release will have the totally tweaked settings for everyone to test without having to change their own stuff.

    :):D:laugh::good:
    111
    Kernel Emergency Settings Reset Zip

    Alright so here's something that's been requested for awhile.

    I wrote it up recently with Franco's stamp of approval, so I'm posting it here now. Please direct people back to this post from other threads.

    This can/should be everyone's go-to when experiencing problems after updating to a new kernel build, you get stuck in a bootloop, or you think there's a conflict between ROM and kernel (or kernel tweaking app) you can't track down, since likely some leftover settings (voltages, etc.) are at fault. It's also useful if you just want to make sure you're running clean defaults. This should work on any device franco.Kernel and f.Ku support, as well as a variety of other devices, kernels and control apps: eXperience (Free/Pro), GLaDOS Control, TricksterMod, Trinity Kernel Toolbox, ROM Toolbox (Lite/Pro), SetCPU, Faux123 Kernel Enhancement Project, Performance Control and Synapse.

    Flashing this via custom recovery of your choice will delete the kernel app settings file(s), disable init.d and userinit.d scripts by moving them to a subfolder (/system/etc/init.d/off/ and /data/local/userinit.d/off/ respectively) and wipe cache and dalvik-cache for good measure.

    Hopefully it helps!


    Note: If your ROM has a Performance/Tweaking App built-in you should also manually disable any Set On Boot options it has. For example, I couldn't include clearing CM's Advanced Settings since they're built into the main com.android.settings/Settings.apk along with a lot of other Android OS settings (APNs, Developer Options, etc.), so to run clean and without conflicts on CM you need to unset them yourself.

    You should also avoid having more than one control app installed at a time. Conflicts have been reported even with everything "unset" in two apps.

    I also chose not to disable anything your ROM may have in /data/cron or /system/addon.d since some rely on it heavily, so you can choose to review those directories' contents and whether you want to leave them enabled on your own. I also left out disabling sysctl.conf since that's done by f.K and the Franco's Dev Team scripts, and also seemed a bit heavy-handed for this zip script.



    Download counts for the previous versions: 790; 2678.
    105
    Sure. Happy to post my franco.Kernel settings here for anyone who wants to try them. I'll keep these up-to-date if I change them. :)

    These are my f.K settings, my DirtyV settings can be found here.
    Device: Galaxy Nexus
    Max Frequency: 1305 MHz
    Min Frequency: 384 MHz
    Governor: interactive
    Governor Tunables: a_h_d 15000 / g_h_l 95 / h_f 729600 Hz / m_s_t 45000 / t_r 15000 / i_b_f 1036800 Hz / t_l 85 / t_s 80000 / b_d 1000000
    IO Scheduler: row
    IO Scheduler Tunables: h_r_q 100 / r_r_q 75 / h_s_q 5 / r_s_q 4 / r_w_q 4 / l_r_q 3 / l_s_q 2 / r_i 15 / r_i_f 25
    Read Ahead Buffer: 512; NR Requests: 512
    TCP Congestion Avoidance Algorithm: westwood
    Screen Off Max Frequency: 537 MHz

    Color Multipliers: 230 235 340
    RGB Gamma: -4 0 5
    Trinity Contrast: -22; OMAP4 Gamma: 4; CAB: Disabled

    Sent from franco.Kernel updater app:
    https://play.google.com/store/apps/details?id=com.franco.kernel

    The following voltages are just as a reference. DO NOT enter them; your device may not be able to handle them this low, causing freezes and reboots. They are here so that people can compare their stable voltages after following the UV guides linked below, to see how our devices compare. Every device is different, so again, DO NOT enter them.
    mpu_voltages:
    1804mhz: 1425 mV
    1728mhz: 1375 mV
    1612mhz: 1325 mV
    1536mhz: 1275 mV
    1420mhz: 1225 mV
    1305mhz: 1175 mV
    1228mhz: 1125 mV
    1036mhz: 1075 mV
    729mhz: 925 mV
    537mhz: 825 mV
    384mhz: 775 mV
    192mhz: 725 mV

    iva_voltages:
    430mhz: 1125 mV
    332mhz: 1025 mV
    266mhz: 925 mV
    133mhz: 825 mV

    core_voltages:
    512mhz: 1050 mV
    384mhz: 975 mV
    153mhz: 800 mV
    There are some battery savings from UVing but they aren't extreme. If you do not know how UVing works and/or you can't/won't read to properly build your own voltage profile, then just stick with the defaults Franco has already UVed. If you do still want to learn to UV then, once again, everyone should build their own voltage profile for their own device. Read this, this, this, and this for starters on UV methods. You don't know how your device will do until you learn and try.

    As a sidenote, if anyone else wants to share their voltages for comparison the easiest way is to copy the contents of the 3 voltage files (mpu/iva/core) in /sys/class/misc/customvoltage/ - they look (almost) exactly as the sections above.
    Fsync on just in case anything ever happens I want my data protected. That said I do disable it temporarily if I ever want a bit more performance in an app or game. SR is hardcoded disabled in the latest builds.

    The other thing worth noting is I set my color settings on boot with an init.d script. Doing it that way you can end up with a completely different result from the same values. The contrast, blacks and colors are much more natural. Also it's seamless which is nice; they take effect during the Google logo. Attached is my init.d script for that. Alter it to your own color settings, remove the .txt extension, push to /system/etc/init.d/ and set the correct perms; rwxr-xr-x (chmod -R 755 /system/etc/init.d in Terminal Emulator).

    900colorsettings can be found with my other init.d scripts (from Franco Dev Team), here: https://s.basketbuild.com/filedl/devs?dev=osm0sis&dl=osm0sis/scripts/900colorsettings

    Note: On my new replacement screen, setting the color multiplier too early in the boot (any time before the boot animation) made everything look dark, oversaturated, uncontrasted and dusky; basically the opposite of the way it used to work on my old panel. Adding sleep 2; before that line in the init.d script fixed this, so experiment if your panel is more like my new one, and the init.d as-is after you put in your settings makes it look worse.

    [ New init.d script with my new colors. I need the sleep 4 because of my problem in my "Note" above, so comment it out if you don't need it, it will make it look worse. Previous download counts were 1880, 646, and 307. Thanks everyone! ]