Database Users

Do you overclock your N7?

Do you?
Do you keep it overckocked for a longer period, permanently, or just when/while you need it? How much (exact frequencies would be cool) I'm thinking of OCing mine (both CPU and GPU) since some games like NOVA 3 lag on occasions but not sure how safe/advisable it is.
Sent from my Nexus 7 using Tapatalk HD

I don't think it's needed. I've heard that OC won't help much with gaming, but you can definitely try

I don't yet - I might later. My N7 is still less than a month old.
The device manufacturers (e.g. Asus in this case) have motivations to "not leave anything on the table" when it comes to performance. So, you have to ask yourself - why would they purposely configure things to go slowly?
After all, they need to compete with other handset/tablet manufacturers, who are each in turn free to go out and buy the exact same Tegra SoC (processor) from Nvidia.
At the same time, they know that they will manufacture millions of units, and they want to hold down their product outgoing defect levels and in-the-field product reliability problems to an acceptable level. If they don't keep malfunctions and product infant mortality down to a fraction of a percent, they will suffer huge brand name erosion problems. And that will affect not only sales of the current product, but future products too.
That means that they have to choose a conservative set of operating points which will work for 99+ % of all customer units manufactured across all temperature, voltage, and clock speed ranges. (BTW, Note that Asus didn't write the kernel EDP & thermal protection code - Nvidia did; that suggests that all the device manufacturers take their operating envelope from Nvidia; they really don't even want to know where Nvidia got their numbers)
Some folks take this to mean that the vast majority of units sold can operate safely at higher speeds, higher temperatures, or lower voltages, given that the "as shipped" configuration will allow "weak" or "slow" units to operate correctly.
But look, it's not as if amateurs - hacking kernels in their spare time - have better informed opinions or data about what will work or won't work well across all units. Simply put, they don't know what the statistical test properties of processors coming from the foundry are - and certainly can't tell you what the results will be for an individual unit. They are usually smart folks - but operating completely in the dark in regards to those matters.
About the only thing which can be said in a general way is that as you progressively increase the clock speed, or progressively weaken the thermal regulation, or progressively decrease the cpu core voltage stepping, your chances of having a problem with any given unit (yours) increase. A "problem" might be (1) logic errors which lead to immediate system crashes or hangs, (2) logic errors (in data paths) that lead to data corruption without a crash or (3) permanent hardware failure (usually because of thermal excursions).
Is that "safe"?
Depends on your definition of "safe". If you only use the device for entertainment purposes, "safe" might mean "the hardware won't burn up in the next 2-3 years". Look over in any of the kernel threads - you'll see folks who are not too alarmed about their device freezing or spontaneously rebooting. (They don't like it, but it doesn't stop them from flashing dev kernels).
If you are using the device for work or professional purposes - for instance generating or editing work product - then "safe" might mean "my files on the device or files transiting to and from the cloud won't get corrupted", or "I don't want a spontaneous kernel crash of the device to cascade into a bricked device and unrecoverable files". For this person, the risks are quite a bit higher.
No doubt some tool will come in here and say "I've been overclocking to X Ghz for months now without a problem!" - as if that were somehow a proof of how somebody else's device will behave. It may well be completely true - but a demonstration on a single device says absolutely nothing about how someone else's device will behave. Even Nvidia can't do that.
There's a lot of pretty wild stuff going on in some of the dev kernels. The data that exists as a form of positive validation for these kernels is a handful of people saying "my device didn't crash". That's pretty far removed from the rigorous testing performed by Nvidia (98+% fault path coverage on statistically significant samples of devices over temperature, voltage, and frequency on multi-million dollar test equipment.)
good luck!
PS My phone has it's Fmax OC'ed by 40% from the factory value for more than 2 years. That's not a proof of anything really - just to point out that I'm not anti-OC'ing. Just trying to say - nobody can provide you any assurances that things will go swimmingly on your device at a given operating point. It's up to you to decide whether you should regard it as "risky".

Wow thanks for your educational response, I learned something. Great post! I will see if I will over clock it or not since I can play with no problems at all, it is just that it hics up when there is too much stuff around. Thanks again!
Sent from my Nexus 7 using Tapatalk HD

With the proper kernel its really not needed. Havent really seen any difference,aside from benchmark scores(which can be achieved without oc'ing)
Sent from my Nexus 7 using XDA Premium HD app

Yes, I run mine at 1.6 peak.
I've come to the Android world from the iOS world - the world of the iPhone, the iPad, etc.
One thing they're all brilliant at is responsive UI. The UI, when you tap it, responds. Android, prior to 4.1, didn't.
Android, with 4.1 and 4.2, does. Mostly.
You can still do better. I'm running an undervolted, overclocked M-Kernel, with TouchDemand governor, pushing to 2 G-cores on touch events.
It's nice and buttery, and renders complex PDF files far faster than stock when the cores peak at 1.6.
I can't run sustained at 1.6 under full load - it thermal throttles with 4 cores at 100% load. But I can get the peak performance for burst demands like page rendering, and I'm still quite efficient on battery.
There's no downside to running at higher frequencies as long as you're below stock voltages. Less heat, more performance.
If you start pushing the voltages past spec, yeah, you're likely into "shortening the lifespan." But if you can clock it up, and keep the voltages less than the stock kernel, there's really not much downside. And the upside is improved page rendering, improved PDF rendering, etc.
Gaming performance isn't boosted that much as most games aren't CPU bound. That said, I don't game. So... *shrug*.

Bitweasil said:
I can't run sustained at 1.6 under full load - it thermal throttles with 4 cores at 100% load.
Click to expand...
Click to collapse
@Bitweasil
Kinda curious about something (OP, allow me a slight thread-jack!).
in an adb shell, run this loop:
# cd /sys/kernel/debug/tegra_thermal
# while [ 1 ] ; do
> sleep 1
> cat temp_tj
> done
and then run your "full load".
What temperature rise and peak temperature do you see? Are you really hitting the 95C throttle, or are you using a kernel where that is altered?
I can generate (w/ a mutli-threaded native proggy, 6 threads running tight integer loops) only about a 25C rise, and since the "TJ" in mine idles around 40C, I get nowhere near the default throttle temp. But I am using a stock kernel, so it immediately backs off to 1.2 Ghz when multicore comes on line.
Same sort of thing with Antutu or OpenGL benchmark suites (the latter of which runs for 12 minutes) - I barely crack 60C with the stock kernel.
?
bftb0

The kernel I'm using throttles around 70C.
I can't hit that at 1200 or 1300 - just above that I can exceed the temps.
I certainly haven't seen 95C.
M-Kernel throttles down to 1400 above 70C, which will occasionally get above 70C at 1400, but not by much.

Bitweasil said:
The kernel I'm using throttles around 70C.
I can't hit that at 1200 or 1300 - just above that I can exceed the temps.
I certainly haven't seen 95C.
M-Kernel throttles down to 1400 above 70C, which will occasionally get above 70C at 1400, but not by much.
Click to expand...
Click to collapse
Thanks. Any particular workload that does this, or is the throttle pretty easy to hit with arbitrary long-running loads?

Odp: Do you overclock your N7?
I'll never OC a quadcore phone/tablet, I'm not stupid. This is enough for me.
Sent from my BMW E32 using XDA App

I've over clocked my phone, but not my N7. I've got a Galaxy Ace with a single core 800MHz processor OC'd to 900+. The N7 with its quad core 1.3GHz is more than enough for doing what I need it to do. Using franco.Kernel and everything is smooth and lag-free. No need for me to overclock
Sent From My Awesome AOSPA3.+/franco.Kernel Powered Nexus 7 With XDA Premium

Impossible to do so can't even get root but did manage to unlock the bootloader
Sent from my Nexus 7 using xda app-developers app

CuttyCZ said:
I don't think it's needed. I've heard that OC won't help much with gaming, but you can definitely try
Click to expand...
Click to collapse
I'm not a big OC'er, but I do see a difference in some games when I OC the GPU. It really depends on the game and what is the performance bottleneck. If the app is not Kernel bound than an OC won't make much difference. Must games are I/O and GPU bound.
Sent from my N7 using XDA Premium
Dirty AOKP 3.5 <&> m-kernel+ a34(t.10)

I've overclocked all of my devices since my first HTC hero. I really don't see a big deal with hardware life.
I know that this n7 runs games better at 1.6ghz than at 1.3ghz.
First thing I do when I get a new device is swap recovery and install aokp with the latest and greatest development kernel. Isn't that why all this great development exists? For us to make our devices better and faster? I think so. I'd recommend aokp and m-kernel to every nexus 7 owner. I wish more people would try non-stock.

scottx . said:
I've overclocked all of my devices since my first HTC hero. I really don't see a big deal with hardware life.
I know that this n7 runs games better at 1.6ghz than at 1.3ghz.
First thing I do when I get a new device is swap recovery and install aokp with the latest and greatest development kernel. Isn't that why all this great development exists? For us to make our devices better and faster? I think so. I'd recommend aokp and m-kernel to every nexus 7 owner. I wish more people would try non-stock.
Click to expand...
Click to collapse
Do you mean the pub builds of AOKP? Or Dirty AOKP
Ty

bftb0 said:
Thanks. Any particular workload that does this, or is the throttle pretty easy to hit with arbitrary long-running loads?
Click to expand...
Click to collapse
Stability Test will do it reliably. Other workloads don't tend to run long enough to trigger it that I've seen.
And why is a quadcore magically "not to be overclocked"? Single threaded performance is still a major bottleneck.

Bitweasil said:
Stability Test will do it reliably. Other workloads don't tend to run long enough to trigger it that I've seen.
And why is a quadcore magically "not to be overclocked"? Single threaded performance is still a major bottleneck.
Click to expand...
Click to collapse
Hi Bitweasil,
I fooled around a little more with my horrid little threaded cpu-blaster code. Combined simultaneously with something gpu-intensive such as the OpenGL ES benchmark (which runs for 10-12 minutes), I observed peak temps (Tj) of about 83C with the stock kernel. That's a ridiculous load, though. I can go back and repeat the test, but from 40C it probably takes several minutes to get there. No complaints about anything in the kernel logs other than the EDP down-clocking, but that happens just as soon as the second cpu comes on line, irrespective of temperature. With either of the CPU-only or GPU-only stressors, the highest I saw was a little over 70C. (But, I don't live in the tropics!)
To your question - I don't think there is much risk of immediate hardware damage, so long as bugs don't creep into throttling code, or kernel bugs don't cause a flaw that prevents the throttling or down-clocking code from being serviced while the device is running in a "performance" condition. And long-term reliability problems will be no worse if the cumulative temperature excursions of the device are not higher than what than what they would be using stock configurations.
The reason that core voltages are stepped up at higher clock rates (& more cores online) is to preserve both logic and timing closure margins across *all possible paths* in the processor. More cores running means that the power rails inside the SoC package are noisier - so logic levels are a bit more uncertain, and faster clocking means there is less time available per clock for logic levels to stabilize before data gets latched.
Well, Nvidia has reasons for setting their envelope the way they do - not because of device damage considerations, but because they expect to have a pretty small fraction of devices that will experience timing faults *anywhere along millions of logic paths* under all reasonable operating conditions. Reducing the margin, whether by undervolting at high frequencies, or increasing max frequencies, or allowing more cores to run at peak frequencies will certainly increase the fraction of devices that experience logic failures along at least one path (out of millions!). Whether or not OC'ing will work correctly on an individual device can not be predicted in advance; the only thing that Nvidia can estimate is a statistical quantity - about what percent of devices will experience logic faults under a given operating conditon.
Different users will have different tolerance for faults. A gamer might have very high tolerance for random reboots, lockups, file system corruption, et cetera. Different story if you are composing a long email to your boss under deadline and your unit suddenly turns upside down.
No doubt there (theoretically) exists an overclocking implementation where 50% of all devices would have a logic failure within (say) 1 day of operation. That kind of situation would be readily detected in a small number of forum reports. But what about if it were a 95%/5% situation? One out of twenty dudes report a problem, and it is dismissed with some crazy recommendation such as "have you tried re-flashing your ROM?". And fault probability accumulates with time, especially when the testing loads have very poor path coverage. 5% failure over one day will be higher over a 30 day period - potentially much higher.
That's the crux of the matter. Processor companies spend as much as 50% of their per-device engineering budgets on test development. In some cases they actually design & build a second companion processor (that rivals the complexity of the first!) whose only function is to act as a test engine for the processor that will be shipped. Achieving decent test coverage is a non-trivial problem, and it is generally attacked with extremely disciplined testing over temperature/voltage/frequency with statistically significant numbers of devices - using test-vector sets (& internal test generators) that are known to provide a high level of path coverage. The data that comes from random ad-hoc reports on forums from dudes running random applications in an undisciplined way on their OC'ed units is simply not comparable. (Even "stressor" apps have very poor path coverage).
But, as I said, different folks have different tolerance for risk. Random data corruption is acceptable if the unit in question has nothing on it of value.
I poked my head in the M-kernel thread the other day; I thought I saw a reference to "two units fried" (possibly even one belonging to the dev?). I assume you are following that thread ... did I misinterpret that?
cheers

I don't disagree.
But, I'd argue that the stock speeds/voltages/etc are designed for the 120% case - they're supposed to work for about 120% of shipped chips. In other words, regardless of conditions, the stock clocks/voltages need to be reliable, with a nice margin on top.
Statistically, most of the chips will be much better than this, and that's the headroom overclocking plays in.
I totally agree that you eventually will get some logic errors, somewhere, at some point. But there's a lot of headroom in most devices/chips before you get to that point.
My use cases are heavily bursty. I'll do complex PDF rendering on the CPU for a second or two, then it goes back to sleep while I read the page. For this type of use, I'm quite comfortable with having pushed clocks hard. For sustained gaming, I'd run it lower, though I don't really game.

PVS Bin ?

So how does PVS BIN affects performance ?
a cpu with pvs bin 4 is a lot better than a CPU with PVS Bin 1 ?

http://forum.xda-developers.com/showthread.php?t=2443934

szabyka95 said:
So how does PVS BIN affects performance ?
a cpu with pvs bin 4 is a lot better than a CPU with PVS Bin 1 ?
Click to expand...
Click to collapse
.... I have 4 and no... can't OC, UC, UV... basically anything besides stock values the "lot better" cpu rejects...
Might be also the custom kernels fault ... who knows
Till now the pvs bin has zero info value...

szabyka95 said:
So how does PVS BIN affects performance ?
a cpu with pvs bin 4 is a lot better than a CPU with PVS Bin 1 ?
Click to expand...
Click to collapse
[For reference] http://forum.xda-developers.com/showthread.php?t=2215710
There seems to be a bit of confusion, about the significance of the PVS value. They relate to Process Corners, and in part to threshold voltage, there is a lot more to it than that, but I'll keep it simple.
So far we've seen PVS values of between 0 to 6.
0 seems to indicate a SLOW corner, this means that its leakage current is lower than a 6, but its timings are slower. In theory, this chip should be good for power consumption, but offer less overclocking potential.
So, 6 means a FAST corner, this means that its leakage current is higher than a 0, but its timings are faster. Again, theoretically this chip offers good overclocking potential, at the expense of possibly higher power consumption.
Firstly, don't worry about it, all these chips have to pass Qualcomm's quality assurance, and lastly a higher PVS number is not necessarily the best, it depends on your priorities.

What you said was correct, I couldnt have explained it that well.
---------- Post added at 02:13 PM ---------- Previous post was at 02:10 PM ----------
PAGOT said:
.... I have 4 and no... can't OC, UC, UV... basically anything besides stock values the "lot better" cpu rejects...
Might be also the custom kernels fault ... who knows
Till now the pvs bin has zero info value...
Click to expand...
Click to collapse
Its just binning based on samples from those batches, you could still end up with an OC dud despite having higher PVS as they only sample a few and cant test every single one. But as the guy before me said they all meet quality assurance standards.
Lower voltage can mean lower heat, but there are other factors also at play.

What's your CPU PVS bin #?

Just out of curiosity, I 'd like to know what everyone's cpu PVS binning is. This makes little difference unless you're trying to undervolt, but it doesn't hurt to know.
Non-Root How To:
Use a file browser (I used Root Browser) and navigate here:
Code:
/sys/module/clock_krait_8974/parameters/table_name
Open up "table_name" as a text file. Mine read: qcom,speed3-pvs7-bin-v1. My PVS bin # being 7 on a scale of 0-15. 0 needing the most volts, 15 needing the least at corresponding frequencies (I think I got that right). Overly simplified that would be higher binning=better, but again this makes very little difference.
Here's a example of stock volatges at 2.5 GHz for the MSM8974AC Rev 1:
Code:
PVS 0- 2.5GHz @ 1.12V
PVS 7- 2.5GHz @ 1.05V
PVS 15- 2.5GHz @ 0.97V
Here's a thread from the OnePlus One forums that's helpful if you want to know more:
http://http://forum.xda-developers.com/oneplus-one/general/info-cpu-binning-concept-overclocking-t2817105/ (Note: Moto X's chipset seems most similar to the MSM8974AC Rev 1 or at least has the same binning)

Thats pretty interesting, never heard of this before.

Mine says 6. Guess mine is using a bit more volts?

Mine says 3. Huh?

5...v1 which according to one plus forums means 2.3ghz?? Sad times v2 is 2.5 apparently

Mine said pvs4, but what does that mean?
Is lower better, or higher?
I googled, but noone else seems to be sure either.

tacosrdelicioso said:
5...v1 which according to one plus forums means 2.3ghz?? Sad times v2 is 2.5 apparently
Click to expand...
Click to collapse
No where did you have this from?
The moto x has the msm8974ac and this one has 2,5GHz... According to cpu-z 2.46GHz (or more exactly 2457.6 MHz says antutu device info page)
Msm8974ab has 2.3GHz.

Yeah, the X uses the AC @ 2.5GHz. I think that's what the speed # means. The version in "table_name" is the PVS version not the CPU version. Not sure what that is though. Maybe the parameters used in sorting?

Mine says 8.

8 here as well... Damn had a 13 on my old moto x lol

jphilippon said:
Mine says 8.
Click to expand...
Click to collapse
Mine says 8 too... ... ...

Mine is also 8

6 here.
Sent from my XT1097 using XDA Free mobile app

Mines a 8

6 for me

8 also

6 here

9 here

mines a 7
Sent from my XT1092

[email protected]:/ $ cat /sys/module/clock_krait_8974/parameters/table_name
qcom,speed3-pvs8-bin-v1

PVS Bin

Update: I added a poll.
What do you guys have for PVS Bin.
PVS 5 on mine.
You do not need root, I used RootExplorer ironically enough.
Steps:
Go to sys/module/clock_krait_8974/parameters
Open table_name

PVS 7, bin v1
is it good or bad? lol

Higer the PVS number lower the voltages for the frequencies in the table.
However its not guaranteed that a higher PVS Bin CPU can OC higher than a lower binned part as they take samples when doing binning, so there could be lower binned parts that OC just as high as higher binned parts and vice a verse.
HD2Owner did a nice table here:
[GUIDE] Snapdragon 805/801/800/600 Clock & Voltage (PVS bin) guide
http://forum.xda-developers.com/htc-one-m8/general/guide-snapdragon-801-clocking-voltage-t2807173

PVS 6

Speed 3, PVS 8 v1

speed3-pvs6-bin-v1

PVS9... not useful without DooMKernel

AndroPlus said:
PVS9... not useful without DooMKernel
Click to expand...
Click to collapse
It is useful since it uses less power and heats less by CPU clock voltage ratio set by Qualcomm...
Ok just to be clear all are Speed 3 and v1 but PVS is different, mine is 8

PVS 8, you have nice one. I am usually on the low side with my luck on most devices lol.

PVS 8 for me too :good:

PVS12
Sent from my D6503 using XDA Free mobile app

PSV 11

pvs4 [emoji22]

Pvs 8. What is the highest?

I believe it's 15.

pvs4

pvs7

In my 4 exchanges this week for defects, PVS Bin increased each time lol. Went from 5,6,7,8.
PVS 8

.

Martin213 said:
pvs15
Click to expand...
Click to collapse
Wow you got the highest possible , nice.
Guys I added a poll, please vote.

[GUIDE][Nikel] Helio X20 power saving settings with (almost) stock performance.

Hi,
I've prepared two small CPU "fixes" for Xiaomi Redmi Note 4/4X Nikel (Mediatek MT6797 Helio X20 CPU).
There are several fixes on the web, but none of them actually worked good.
As you probably know, CPU in our devices are controlled by both standard cpufreq interactive linux CPU goveror and proprietary Mediatek Perfservice.
The problem is, that Perfservice tends to set max frequencies and waking up big cores on certain events like launching/switching app or simpy touching or rotating screen.
Providing excellent user experience, but wasting battery power at the same time.
Simply disabling Perfservice isn't good idea, as - contrary to governor settings - both A72 cores will be limited to 1,5Ghz (down from 2,1Ghz).
So while this is nice and power saving, it also limits single core performance considerably (to about 1200 points in Geekbench 4).
Multicore performance seems unaffected, though.
My modification aim to reduce power consumption and temperatures while still providing (almost) stock speed.
It comes in two "flavours", and please note you only need ONE of them (your choice).
Two files are included in this post:
perfservscntbl.txt is *only* for flavour 1.
unlock.sh is *only* for flavour 2.
But you can use both if you want to switch between flavours.
And of course they come without any warranty - I don't take responsibility for *any* damage and bricked devices.
They were prepared in two hours time, in fact I rooted my phone yesterday and have it for a week - so I didn't do much testing.
If you don't know what are you doing, never used linux before etc - please simply don't do it.
If you have TWRP use it and make backup just in case.
Prequisities :
- Unlocked and rooted Helio X20 device
Flavour 1
This modification alters perfservice settings to much simpler and less aggresive.
- backup your stock /system/etc/perfservscntbl.txt
- replace it with included file
- give it 644 permissions (rw-r--r--)
- reboot
That's it.
Flavour 2
This modification disables perfservice entirely and unlocks A72 cores high speed for standard governor
- disable mediatek perfservice by setting
ro.mtk_perfservice_support = 0
in your build.prop (/system/build.prop)
- reboot
- run incuded bash script with root privileges to unlock max frequencies (linux proc changes are not permanent, only until reboot!).
You can use something like ROMToolboxPro to execute script automatically after each reboot.
Or use terminal as root user to set it manually (just look what's inside).
Notes:
Due to lower average frequencies (and time that interactive governor will need to ramp them up) performance will most likely be still slightly inferior to stock and you will ocassionally feel UI shuttering.
Even though you should still be able to hit 1500+/4800 in Geekbench 4 on both variants, just like stock.
I hope it will help.
Q&A:
Q) How much more SOT and standby can I achieve with these patches?
A) I really don't have any idea. I don't do such tests.
Q) Which flavour is faster?
A) Probably first one, especially for UI. Tends to utilize mid cluster more. Second one is more energy-saving. But on multicore geekbench test I got opposite results (tested just once).
Q) How can I check that it is working?
A) Try DevCheck and observe frequencies before and after mod. Try switching applications, rotating and touching screen.
Q) Can I improve battery life even further and still have usable phone (without buying snapdragon version)?
A) Yes, you can disable A72 cores entirely and have ordinary octa-core CPU (4*1.8Ghz + 4*1.4Ghz):
echo Low_Power > /proc/ppm/mode
Performance will be around 650/3500 Geekbench4 points.
Alternatively you can do it this way (don't know what's the difference yet)
echo 2 > /proc/ppm/policy/hica_power_state
Or disable both high and mid cluster, and leave only low cluster (kind of super powersaving mode, x20 becomes quad core)
echo 0 > /proc/ppm/policy/hica_power_state
(echoing -1 there will re-enable all clusters)
Q) Can I improve perfservice settings further?
A) Yes, I spent only about one hour on them, and speak polish not chinese, so almost certainly they can be improved.
http://blog.csdn.net/zhangyongfeiyong/article/details/52946781
For example I don't have any idea what's the difference between vcore 1 and 3.
Even though 3 seems to be selected for better performance, I haven't noticed any speed difference.
I set it to 1, so it may run undervolted. Maybe. Hopefully. You can also remove vcore entries entirely.
I'm using flavour 2 though, so I'm not gonna work on it anymore.
Q) My AnTuTu score (or other benchmark score, or game X FPS) went down!
A) Unfortunately, this is what you should expect from battery saving modifications.
If you need top-notch performance these modifications are not for you.
You can try altering cpufreq governor settings, though.
Q) Can I improve it further by altering cpufreq governor settings?
A) Probably yes, but not much. Default cpufreq settings are actually quite good.
Q) Will you tune cpufreq governor for my specific purposes?
A) I'm sorry I don't have time for it. As I said, default one is quite nice already.
Q) Can I improve overall device performance further?
A) Yes, you can for example enable zRAM and tune I/O schedulers, queues and low memory killer YMMV, though. And it depends on your workload.
Q) I really don't know how to do it, can you provide one click installer?
A) No, and I strongly advise against doing it if you don't understand.
Q) My device exploded!
A) You have been warned

amazing mate! waiting for some reviews of this, i am going to try it

how to input these codes:
Alternatively you can do it this way (don't know what's the difference yet)
echo 2 > /proc/ppm/policy/hica_power_state
Or disable both high and mid cluster, and leave only low cluster (kind of super powersaving mode, x20 becomes quad core)
echo 0 > /proc/ppm/policy/hica_power_state

iflawlietasgod said:
how to input these codes:
Alternatively you can do it this way (don't know what's the difference yet)
echo 2 > /proc/ppm/policy/hica_power_state
Or disable both high and mid cluster, and leave only low cluster (kind of super powersaving mode, x20 becomes quad core)
echo 0 > /proc/ppm/policy/hica_power_state
Click to expand...
Click to collapse
You need to either access terminal with superuser rights (look for Terminal Emulator) or use app that can execute shell scripts (like Rom Toolbox or FX Explorer).

Tried echo 1 > /proc/ppm/policy/hica_power_state
It will disable your 2x A72 + 4x A53 1.4GHz, leaving you with 4x A53 1.8GHz. Sounds like "not-so-aggressive ultra powersaving mode" for me

TwelveMoon said:
Tried echo 1 > /proc/ppm/policy/hica_power_state
It will disable your 2x A72 + 4x A53 1.4GHz, leaving you with 4x A53 1.8GHz. Sounds like "not-so-aggressive ultra powersaving mode" for me
Click to expand...
Click to collapse
But you'll lose lowest powered A53 cores. I wonder if L cores (1.8Ghz) consume more power than LL cores (1.4Ghz) when doing nothing.
Even in such case, this setting should be ideal for long term gaming - decent performance with probably no thermal throttling
Ah, there is also "/proc/ppm/mode" setting. I set it to "Just_Make" recently - seems to be between "Low_Power" and "Performance". Just_make doesn't limit any frequecies or affect GeekBench score.

sobrus said:
But you'll lose lowest powered A53 cores. I wonder if L cores (1.8Ghz) consume more power than LL cores (1.4Ghz) when doing nothing.
Even in such case, this setting should be ideal for long term gaming - decent performance with probably no thermal throttling
Click to expand...
Click to collapse
Yeah, I've tried to use echo 0 on /proc/ppm/policy/hica_power_state as well, and it turns out that 4x A53 1.4GHz is still usable for low-end gaming. Tried Antutu benchmarking on echo 0 setting + CPU hifreq turned down to 1092MHz by tweaking governor values, I still get 50K++, which is quite good for me.
I also accidentally locked my lowest cluster to the lowest frequency possible (221 MHz) by simultaneously change the target_loads and go_hispeed_load values to beyond 100 (120 for example). My device became unimaginably laggy at that time :laugh:
FYI, those tweaks give me extra up to 2 hrs of SOT, which is good for someone who spent a lot of time with this device like me :laugh:

I have my go_hispeed_load far beyond 100 (I don't quite like the idea of "hispeed" and "boost" and it's OK - not excellent, but passable, closer to conservative governor), but any target_loads beyond 90 will make UI choppy and beyond 100, as you noticed, will lock on lowest frequency.
If someone needs better UI experience, setting it to 80-85 would be my first experiment, then reducing timer to 10000.
Extra 2hr is nice improvement

flavour 2 is only use 2xA72 only? middle and low is disable?

Flavour 1 - stuck on boot logo.
IS it for miui 8 only?

I'm a little interested in htat. I have a Leeco s3 running MIUI 9 beta.
My problem is that in RR3 the a72 idles 1ghz to 1.5ghz, not more. And sometimes game is a little laggy.
Your tweak would fix that?
Is there anything I can do with kernel auditor more safety?

Leeco S3 uses Qualcomm Snapdragon 652, so my tweak won't help.
And unfortunately I don't know have any Snapdragon phone to prepare tweaks for you
You can try to set performance cpu governor, but I don't know if it is possible on your device.
Are you sure your device is not throttling due to high temperatures?

sobrus said:
Leeco S3 uses Qualcomm Snapdragon 652, so my tweak won't help.
And unfortunately I don't know have any Snapdragon phone to prepare tweaks for you
You can try to set performance cpu governor, but I don't know if it is possible on your device.
Are you sure your device is not throttling due to high temperatures?
Click to expand...
Click to collapse
Maybe he meant x626?

These tweaks confirmed to be working on LeEco Le S3 X626 (MTK Helio X20)! The result is REALLY noticeable. I'd say around 50% increase in battery life. (I used method 2)

How did you know the policy command, "echo 0 > /proc/ppm/policy/hica_is_limit_big_freq"
What is "echo 0"?
And what is mean by "hica_is_limit_big_freq"?
Where i can find any other policy command?

cheapster8 said:
These tweaks confirmed to be working on LeEco Le S3 X626 (MTK Helio X20)! The result is REALLY noticeable. I'd say around 50% increase in battery life. (I used method 2)
Click to expand...
Click to collapse
How did you use method 2?
Guide me please
Sent from my LEX626 using Tapatalk

Can anyone explain me how to install that archive?and how to increase the working time of the phone with this archive?

@Votrexx
I don't understand what your problem is
@BLINGER-PC, @CSSman
You need to ROOT your phone first, which may void your warranty, and by doing these changes improperly you CAN brick your phone too.
That's why I'm not going to give explanations easier than "modify your build.prop and echo this value". It is all you need to do.
You need basic understanding how linux and android work before you begin to be sure you won't damage your phone.
Sorry.

sobrus said:
@Votrexx
I don't understand what your problem is
@BLINGER-PC, @CSSman
You need to ROOT your phone first, which may void your warranty, and by doing these changes improperly you CAN brick your phone too.
That's why I'm not going to give explanations easier than "modify your build.prop and echo this value". It is all you need to do.
You need basic understanding how linux and android work before you begin to be sure you won't damage your phone.
Sorry.
Click to expand...
Click to collapse
What to modify at build.prop
?

ro.mtk_perfservice_support = 0
It is written in the first post.