[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8] - OnePlus 3 & 3T Cross Device Development

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
for OOS-N, and LOS-N​
Code:
/* *** Disclaimer
* I am not responsible for bricked devices, dead SD cards, thermonuclear war,
* or you getting fired because the alarm app failed. Please do some research
* if you have any concerns about features included in this KERNEL
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
* BOOM goes the Dynamite
*/
I am releasing this kernel because I like to share my work and have had requests to do so and, lastly, because we needed yet another kernel released for our beloved OP3! I started out at XDA because I wanted to learn and share what I have learned. My goal with this kernel is to be a very fast and stable build that offers some things that the other kernels do not. I also want to initiate Development Discussions among the community. This will be a noob friendly thread as long as users follow two rules. First is to do some research before asking. Most likely your question has already been asked. If not in this thread then in another. Remember to always search first! Second is BE RESPECTFUL. You do these two things and even the most hardened Dev will assist you.
Wanna be notified of an Update? Here is my PushBullet Channel!!
https://www.pushbullet.com/channel?tag=renderkernel
Current Features
General List:
* EAS Only
* Built with LINARO 6.x
* Updated with CAF LA.UM.5.5
* IO Scheds - FIOPS, CFQ, BFQ, ROW, DEADLINE, NOOP, and ZEN Schedulers
* Flar Sound Control
* Wake Gestures - DT2W, S2W, and S2S
* Complete Color Calibration Thanks to @savoca
* F2FS Support
* Adrenoboost
* USB Fast Charging
I recommend Kernel Aduitor for making kernel changes
Kernel Downloads:
LOS-(EAS/HMP) Downloads
OOS-(EAS/HMP) Downloads
Instructions:
* Boot into Recovery
* (Recommended) Make a complete backup of everything!
* At least backup BOOT via TWRP
* Flash Zip
* Reboot
THANKS!!!!
First I want to say thank you to everyone who has answered my questions and responded to my pm's when I know they are busy with their own lives. Pretty much everyone I have come into contact with here on XDA has been truly helpful and respectful. Here is a list of people that had helped me in one way or the other:
Neobuddy89, ak, myfluxi, Dorimanx, Savoca, Faux123, DespairFactor and Many More!
Thank you guys! Without your contributions to the community we would not have the level of performance, stability and interaction that we have today
Special Thanks!
Donators: @nfin1te, @MrDarkKV, @V1TRU, @Really now @erad1
Source Links:
https://github.com/RenderBroken/OP3-kernel
https://github.com/RenderBroken/OP3-LOS-kernel
https://github.com/RenderBroken/RenderKernel-AnyKernel2
XDA:DevDB Information
[UNIFIED] Render Kernel [OOS-N-EAS-R2][LOS-N-EAS-R8], ROM for the OnePlus 3
Contributors
RenderBroken, Mostafa Wael, joshuous
ROM OS Version: 7.x Nougat
Version Information
Status: Testing
Created 2016-11-23
Last Updated 2017-12-15

Note:
Great write-up from @Mostafa Wael
HMP vs EAS - OxygenOS 4.1.3 stable
Right here we go!
First things first, this is a comparison between two kernels and NOT just two different scheduling systems. With the latter being undeniably the biggest difference between RenderKernel and the stock kernel, changes can extend to other default settings, should @RenderBroken choose to do so. One of which is the default choice of BFQ I/O scheduler instead of the default CFQ I/O scheduler of stock kernel. If you want to have a quick debrief of what (the current implementation of) EAS is all about, read this post here
MMX Hill Dash
HMP - most of the time the game is mainly operated by the big cluster while the little cluster is mostly at the lower end of the frequency table, hovering around the absolute minimum frequency of 307 MHz for most of the time. The big cluster however was noticeably more active, hovering around 1.25 GHz to 1.55 GHz with rare dips below 1 GHz and slightly more often spikes to 1.7 GHz and above. So to sum up HMP's management of the CPU in this particular game, it is safe to state that the game is more or less solely operated by the big cluster, running mostly on the intermediate frequency steps between 1.25 GHz and 1.55 GHz with occasional spikes to 1.7+ GHz and much scarcer dips to sub 1 GHz. As far as performance goes, there are no major complaints. The game runs incredibly smoothly and the game is loaded in a reasonably quick manner; launching the game takes between 8s and 10s from the get-go.
EAS - It's remarked that all 4 cores are active when playing this game, unlike HMP, with the little cluster spending almost all of the time at the 1.11 GHz step with very rare dips to the minimum frequency. While that may sound like a bummer, there is an upside to the surprisingly increased activity of the little cluster. Apparently the big cores have some of the loaded lifted, since the big cluster is being utilised at noticeably lower frequency steps compared to HMP, staying on the 1.11 GHz frequency step much more often, otherwise roaming between 1.25 GHz and 1.55 GHz with very scarce spikes to the max frequency. Like HMP, the game runs flawlessly with no major complaints and surprisingly the game is loaded just as quick as HMP too, if not a tad quicker sometimes! Crikey!
True Skate
HMP - Both clusters are heavily fluctuating with no predictable trend. However, it is quite noticeable that the big cluster can hit the high end of the frequency table quite often. Little cluster is relatively less active, but it is not that dormant either. With that said, it is no wonder that the game runs silky-smooth. However, there were some instances where the frame rate would suddenly drop to around 40-45 fps for mere seconds, where the cause has been determined to be some background tasks being executed like Play Store checking for whether there are apps need to be updated, and social media apps refreshing in the background. Theoretically such an issue would not exist on EAS due to cleverer tasks placement techniques to avoid overstressing the CPU.
EAS - Both clusters spend most of their time at the 1.11 GHz frequency step, with the big cluster ramping up to the max frequency for a considerable amount of time. With that said, a natural consequence would be witnessing one of the most consistently smooth and fluid gaming sessions of that particular game. And even with lots of background processes taking their toll on the silicon, performance is not hindered by any means.
Browsing via Chrome
HMP - Flinging through the webpage will immediately crank up the big cores to max frequency straight away till the content is loaded. Should there be a video to be buffered, the big cores keep operating at medium high frequencies between 1.25 GHz and max frequency with rare dips to minimum frequency. Once all contents are loaded, the big cores gradually get toned down and caged into the lower end of the frequency table. The little cores on the other hand are not wrestling with the controls surprisingly enough, rather sitting most of the time comfortably at 0.96 GHz to 1.1 GHz, with a considerable amount of time spent on the lowest two frequency steps of 307 MHz and 422 MHz. Scrolling through the webpage is reasonably smooth, though sometimes it tends to be a bit unresponsive and wonky if a lot of interactions were present or a lot of content are being loaded while scrolling. As far as battery backup goes, there is no escape that such a task would sip a lot of juice from that tank. And at 18%/hr, there is a lot to be desired when it comes to efficiency, bearing in mind that such a high active drain rate does not guarantee you a flawless silky-smooth UI.
EAS - Like HMP, flinging through the webpage will engage the big cores fully till the page contents are loaded. However, unlike HMP, the big cores do fade out quite faster when the page contents are loaded successfully. Things get much better when there is a video to be streamed, where the video is mainly handled by the little cluster while the big cluster is impressively tamed and utilised at sub 1 GHz frequencies, 0.7 GHz on average, while the little cluster lifts the burden from the furious big cores, operating at frequencies between 1.1 GHz and max frequency of 1.59 GHz. Scrolling through the pages is silky smooth with no hiccups of any sort, even when loading a lot of content while stubbornly scrolling the page, it does not stutter as much as it does on HMP. However, things are not all rosy when it comes to battery drain. Web browsing is undeniably demanding, which makes it logical to see a not-so-impressive 17%/hr drain rate. While it may sound marginally better, web browsing inevitably does take its toll on the battery for sure, and things are not that drastically better when it comes to battery conserving. However, when you couple that with the increased fluidity and consistency gained, EAS is the clear victor.
YouTube streaming
HMP - For such a medium/light workload, it is no wonder seeing the little cluster being noticeably more active than the big cluster, where it spends most of the time on the lower end of the frequency spectrum, with more than 60% spent on the lowest 2 frequency steps of 422 MHz and 307 MHz. However, there were some occasional bumps to a rather unexpectedly higher frequency of 960 MHz, taking around 11% of the total time. While the big cluster was relatively quite dormant, it was not asleep either. With around 7% of the time spent on 1.25 GHz, it is far from being asleep, which raises some eyebrows for sure. It's not that grim though. At 11.6%/hr drain rate, it's highly unlikely to find your phone depleted before lapping some 9 episodes of your favourite TV series, which in my case was the old Top Gear UK.
EAS - Surprisingly enough, there are almost no tangible improvements in battery life while streaming some videos on YouTube. With the consistently reported figure of 11.3%/hr by EXKM battery monitor, I am struggling to say anything other than the fact that battery life is very similar to that of HMPs. Moreover, the frequency distribution is not that all different either. Little cluster is expectedly sitting most of the time at the lowest two frequency steps with much shorter duration at the 480, 556 and 652 MHz steps. Same goes for the big cluster as well, with respective frequency steps considered of course. But rest assured, it is still as highly unlikely to miss out a season of your favourite TV series as with HMP.
Overall battery life
HMP - in the past couple of days, I often read a value between 14%/hr and 16%/hr in EXKM's battery monitor with my mixed not-so-light usage, which is pretty much decent though not perfect and definitely leaves something to be desired in that area. But since I get more than 5 hrs SOT at the end of the day with some little juice left in the tank at the end of the day, I think it is safe to say battery life is good enough for the overwhelming majority of users
EAS - While people may think this is pure EAS terrain, results are not dramatically different from what you get from HMP. Surprisingly enough, I often stumble across an active drain rate between 13%/hr and 15%/hr with approximately the same usage pattern, which is 3%/hr less than what you get from HMP in the best cases. This is a substantial improvement, make no mistake, but that may not live up to the expectations from an energy aware scheduling system. However, an area where EAS truly shines is screen-on idling. Not only does the CPU retreat to the minimum frequency quite quickly, but also remains utterly dormant with absolutely no random spikes, causing a dramatic decrease in the battery drain. This is purely e-book readers heaven for sure! The same cannot be said about HMP for sure.
let's get to the numbers...
App launches
[HMP]
PCMark: (7.13 + 8.32 + 6.65 + 7.00 + 7.85)/5 = 7.39 sec
Slack: (1.60 + 1.78 + 1.79 + 1.65 + 1.75)/5 = 1.71 sec
YouTube: (1.40 + 1.44 + 1.41 + 1.44 + 1.45)/5 = 1.43 sec
Telegram: (0.65 + 0.72 + 0.70 + 0.54 + 0.61)/5 = 0.64 sec
WhatsApp: (1.28 + 0.72 + 1.27 + 1.34 + 1.28)/5 = 0.91 sec
Hangouts: (1.38 + 1.34 + 1.31 + 1.34 + 1.38)/5 = 1.35 sec
Dropbox: (1.25 + 1.26 + 1.37 + 1.22 + 1.21)/5 = 1.26 sec
Chrome: (1.18 + 1.36 + 1.19 + 1.50 + 1.38)/5 = 1.32 sec
Keep: (0.94 + 1.03 + 0.97 + 0.94 + 0.97)/5 = 0.97 sec
MMX Hill Dash: (7.56 + 12.87 + 12.09 + 11.60 + 10.81)/5 = 10.99 sec
Twitter: (1.69 + 1.81 + 1.90 + 1.66 + 1.91)/5 = 1.79 sec
True Skate: (1.60 + 1.69 + 1.62 + 1.59 + 1.54)/5 = 1.61 sec
XDA Labs: (1.41 + 1.53 + 1.47 + 1.48 + 1.52)/5 = 1.48 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Interactive with stock settings and I/O scheduler set to CFQ with 512 KB read ahead buffer size
[EAS]
PCMark: (9.13 + 9.63 + 9.50 + 9.84 + 9.50)/5 = 9.52 sec
Slack: (1.66 + 1.79 + 1.69 + 1.75 + 1.85)/5 = 1.75 sec
YouTube: (1.66 + 1.69 + 1.63 + 1.62 + 1.69)/5 = 1.66 sec
Telegram: (0.69 + 0.66 + 0.63 + 0.59 + 0.78)/5 = 0.67 sec
WhatsApp: (0.75 + 1.19 + 1.16 + 0.97 + 1.21)/5 = 1.06 sec
Hangouts: (1.34 + 1.29 + 1.36 + 1.25 + 1.31)/5 = 1.31 sec
Dropbox: (1.40 + 0.84 + 0.86 + 0.85 + 0.87)/5 = 0.96 sec
Chrome: (1.32 + 1.37 + 1.39 + 1.56 + 1.32)/5 = 1.39 sec
Keep: (0.97+ 0.91 + 0.85 + 0.93 + 0.84)/5 = 0.90 sec
MMX Hill Dash: (11.31 + ---) the game refuses to launch seamlessly, to be investigated later..
Twitter: (2.25 + 2.53 + 2.50 + 2.57 + 2.37)/5 = 2.44 sec
True Skate: (2.00 + 1.58 + 1.71 + 1.75 + 1.74)/5 = 1.76 sec
XDA Labs: (1.72 + 1.44 + 1.47 + 1.53 + 1.43)/5 = 1.52 sec
Test has been done with no active Internet connections (WiFi and mobile data turned off) to ensure that the phone is not bottlenecked by anything but the I/O and the CPU
CPU governor is Schedutil with stock settings and I/O scheduler set to BFQ with 512 KB read ahead buffer size
.
Synthetic Benchmarks
[HMP]
AnTuTu: 148,471
Geekbench 4.1.0: 1733 + 4191
Vellamo - Multicore: 3215
Vellamo - Metal: 3541
Vellamo - Chrome: 4825
[EAS]
AnTuTu: 143840
Geekbench 4.1.0: 1740 + 3290
Vellamo - Multicore: 2511
Vellamo - Metal: 3569
Vellamo - Chrome: 4350
This test was conducted with RenderKernel-OP3-OOS-N-EAS-R1-WALT and OnePlus's inbuilt kernel. OxygenOS version used was OOS 4.1.3 STABLE
Coming up next is a brief technical breakdown of OOS's behind-the-scenes stuff and how OnePlus fiddled around with them by XDA member @chinmai560621 .
Hope such an analysis benefits someone here. Sorry for the delay, but i have been double slapped by life for the past couple of weeks every day....

Reserved
An amazing write up by a talented dev @joshuous:
PELT and WALT
Time for me to flex the analogy muscles.
Just to set things straight, PELT and WALT are different load tracking metrics that try to determine the load of the system. The load will eventually be used by the frequency governor to set the frequency. Think of them (the load tracking metrics) as an employee who is dedicated to announcing how quickly customers are coming into your burger restaurant. The frequency governor is the burger chef, who isn't able to see the number of customers entering, so he has to rely on the announcer in order to know the rate at which he is making burgers. The announcer can say that there are "many" customers, and the chef has to decide how fast to make the burgers based on how he interprets "many".
One announcer can say that 10 customers is "many", while another may say that 20 is "many". An announcer may also attempt to predict the number of customers that will enter based on how many he sees at the current point in time. In this way, burger output is more 'bursty'. For example, there are 10 customers ("many"), then no customers ("none"), then 15 customers ("very many"). The chef works hard, then thinks he can take a break for a moment, then suddenly has to work like crazy to dish out burgers for 15 customers. An oversimplified analogy to WALT.
On the other hand, another announcer may observe a trend of customers and apply some prediction to guess how many customers might come through the door. Using the same customer sequence as before, he may instead tell the chef "many", "some", then "many". So the chef may make burgers even when there are no customers, in anticipation of future customers, but he won't be worked so darn hard all of a sudden. This is less bursty and more consistent. An oversimplified analogy to PELT.
In the same way there are different chefs (e.g. Sched and Schedutil). They have different interpretations of what "many" means to them. That's why their burger outputs may be different even when having the same announcer.
So which is better? It all boils down to your workload, and even so it is difficult to make a conclusion. All I can say is that you must test each mechanism for over a week and check your active drain rate (Ex Kernel Manager is good for this). Active drain rate is a much better measure than SOT. And make sure to keep jumping back and forth between the two to account for anomalies.
Edit: On another note, to complete the analogy... Interactive and HMP is more similar to the chef being the announcer as well. Except for he is able to see less than a dedicated announcer can. I.e the chef (interactive governor) can't look at the queue outside his restaurant but only the ones in his restaurant (so he is partly blind). A dedicated announcer can look at customers inside and outside the restaurant though.
Do note that this has little to do with EAS per se. EAS is a different beast that focuses on optimizing which customers is assigned to which chefs. I'll probably write the analogy for this another time if there is a demand for it

You can't imagine how happy I am to see you here!
Sent from my ONEPLUS A3003 using Tapatalk

Download links says, N6?

ELoTRIX said:
Download links says, N6?
Click to expand...
Click to collapse
See OP#2. Sorry, still updating OP

Work with 3.5.5. cb?
Sent from my ONEPLUS A3003 using XDA-Developers mobile app

isoladisegnata said:
Work with 3.5.5. cb?
Sent from my ONEPLUS A3003 using XDA-Developers mobile app
Click to expand...
Click to collapse
Sorry, it will not work for CB yet. I made that clearer in OP.
I would like to offer support for it though.

TaRsY said:
You can't imagine how happy I am to see you here!
Click to expand...
Click to collapse
Me too!! I love render since lg g2 times.. Thanks Render for coming here

omg another kernel. Im so exited !!!!!!!!
thank you very much!!!
cant wait to test!!!
looks very promissing!!

MBurns2 said:
Me too!! I love render since lg g2 times.. Thanks Render for coming here
Click to expand...
Click to collapse
Thanks! Glad to be here!
nadejo said:
omg another kernel. Im so exited !!!!!!!!
thank you very much!!!
cant wait to test!!!
looks very promissing!!
Click to expand...
Click to collapse
I appreciate the kind words!
Everyone, please remember to provide logs in case of a reboot. I dont like to release such builds but it will happen from time to time. Especially when porting new features such as EAS.
You can get a log from
/sys/fs/pstore/console-ramoops

New build. Fixes default governor not being set properly.
Default gov is supposed to be "SCHED"
R1-T40-EAS

Great work bud
__
v7

RenderBroken said:
New build. Fixes default governor not being set properly.
Default gov is supposed to be "SCHED"
R1-T40-EAS
Click to expand...
Click to collapse
Good to see you here Buddy.. No doubts now we have one more best kernel for our beast OP3. surely gonna use permanently...
Sent from my aicp_oneplus3 using Tapatalk

Render is great just bringing another great kernel to the Oneplus 3

Look who's here.. Render.. One of the most friendly and vocal devs.. Thank you for the kernel mate.. You made opo so amazing..

Flashed looks good!
lets see for next battery cycle.

Great! EAS is really where I was hyped for! Thx for your amazing work!.
I'm going to run it 24 hours and see if there are any reboots, if there won't be ill let you know. I noted that the Cpu frequency stays quite high when there is barely any load? Is this normal?
Edit: issue with standby, couldn't get my phone on when I didn't use it for like 3-4 minutes. Had to reboot, but couldn't reproduce the problem
Issues I encountered:
1. Had an instant where my phone's screen was off for 2 minutes, i couldnt get the screen back on so i had to reboot. Yet i failed to reproduce the issue. (Logs didnt show anything)
2. CPU frequency seems to be really overkilling a task. It doesnt like to stick to 300Mhz either.
Other then that it works smooth and flawless! Even Snapchat is now using all 4 cores instead of only 2 little ones on HMP.

Hi, I know you only support OOS. Having said that, will it cause any problems if I use it over custom roms?

ROM OS Version: 2.3.x Gingerbread
Click to expand...
Click to collapse
Sorry for disturbing, but OP need some correction
Anyway, I'm impatient to test it !

Related

BatteryStatus CPU Scaling: How-to and purpose.

I've been staring at BatteryStatus' CPU Scaling function wondering what good it does if I use it... and how do I use it if I decide that it was useful. I'm sure some users here are wondering the same thing, especially on our low-powered Wizards. Can someone lay it thick for us CPU-shy users?
The CPU Scaling function in BatteryStatus Pro adjusts CPU speed automatically according to CPU usage, so you can get faster speed when using application, ans saves power when you are waiting (i.e. loading a web page).
The rate of scaling is fully adjustable (max speed, min speed, step, threshold, step interval)
Sweet
starkwong; said:
The CPU Scaling function in BatteryStatus Pro adjusts CPU speed automatically according to CPU usage, so you can get faster speed when using application, ans saves power when you are waiting (i.e. loading a web page).
The rate of scaling is fully adjustable (max speed, min speed, step, threshold, step interval)
Click to expand...
Click to collapse
Awesome! Something usable when my phone's bluetooth connected to my car.
Now, how does one set up these options to take advantage of this function?
It'd be better if you search "battery status" (only titles) here..You will come across the battery status development thread, which has all the info you need, plus it points to the home page for the app which also has a manual..
Dont get me wrong but pls search before shooting off questions.
shantzg001 said:
It'd be better if you search "battery status" (only titles) here..You will come across the battery status development thread, which has all the info you need, plus it points to the home page for the app which also has a manual..
Dont get me wrong but pls search before shooting off questions.
Click to expand...
Click to collapse
Well said !
Dont get me wrong but pls search before shooting off questions.
Plz read the forum,you'll find all the answers to your question in here,these kind of questions have been asked hundreds of times in various threads or shud have posted in the appropriate thread from you downloaded your present rom TNT 5.0. Or hit the 'Search' button at the top with your specific word to locate,you'll be amazed.There's no need to start a new thread for this.
Just remember...
More Mhz translates into less power efficency.
ie.
195 mhz (stock speed) = Regular Baterry consuption
240 mhz (overclocked speed) = Over Regular Baterry consuption
260 mhz (overclocked speed) = High Baterry consuption
280 mhz (overclocked speed) = you got the idea
Also remember that when increasing the processor Speed may cause your system to hang or not wakeup if you are using a very low frequency.
Best regards.

[Kernel 3.0.30][RCMixSensationICS][Sense 3.6/4.0][OC 1.7][07JUN][5.6/5.5]

RC TEAM PRESENTS ​
HTC SENSATION ICS KERNEL
Come see ACS for Most recent updates
Feel free to use my kernel source without permission. Its open source so use it as you see fit. Enjoy.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
FEATURES
CIFS
NLS
TUN
TMOBILE WIFI CALLING (Module supported)
OC 1.75ghz if you want to go there. Use setcpu
set to 1.5ghz by default
UV
Better wifi signal now you can connect at a weaker signal -108dbm over stock -88dbm
lower wifi voltage
you can use your flashlight with the battery at 10% over stock 30%
SWAP
ZRAM
Adjustable VDD table
5 I/O schedulers
[CFQ][NOOP][VR][DEADLINE][BFQ]
Perfect Sweep to unlock
Call Recording with app below
Click to expand...
Click to collapse
Click to expand...
Click to collapse
CPU FREQ TABLE​
192000
384000
432000
486000
540000
594000
648000
702000
756000
810000
864000
918000
972000
1026000
1080000
1134000
1188000
1242000
1296000
1350000
1404000
1458000
1512000
1566000
1620000
1674000
1728000​
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Downloads below
CURRENT:
RCMix Sensation 5.5
RCMix Sensation 5.6 (Not working - Compile problems - Don't use!)
PREVIOUS:
RCMIX 5.4
RCMIX 5.4 STOCK GPU
--------------------------------------------------------------------
CALL RECORD APP
--------------------------------------------------------------------
This Kernel features 5 I/O schedulers
To change them download No Frills or System Tuner from the market and and change at will.
To Manually adjust the VDD Table use system tuner from the market or other programs
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Change log
5.6
not working! wait the next build
updated s2w should fix lockscreen fixes
changed some drivers
5.5
updated to linux kernel version 3.0.30
updated sensation kernel updates
5.4
remaned rcmix smartdroid
updated linux kernel 3.0.28
updated sweep to wake (thanks showp1984)
lots of other tweaks. see git for full changelong
5.3
added sweep to unlock(showp1984)
fixed heptic feedback for sense 4(showp1984)
some ondemand tweaks
updated configs
V5.2
tweak ondemand gov
added compiler fixes
added new zip by showp
some other small code changes
V5.1
lowered flashlight usage to 5% battery power remaining
patched linux upstream to 3.0.26
added bfq IO scheduler
boosted banwith of the 2d and 3d gpu cores
changes to the OC
see git for all changes.
V5.0.1
set boot to 1512 forgot that one lol
v5
added adjustable VDD Table
added VR IO sched
UV more
multitouch tweaks
OC adjustments
see git for more
V4.3
OC to 1.72
set freq by default
set min freq to 192000
set max freq to 1.566
enabled more in configs
V4.2
tweaked OC
added muli touch tweak
updated configs
built cifs and nls into kernel
probably more
V4.1
built kernel with newest gcc compiler 4.5.2
updated htc battery core driver
OC GPU 2D core
OC GPU 3D core
updated htc sense 4 video driver
enabled zram and swap
V3
added linux kernel upstream .25
added lagfree gov
v2
added lots of wifi tweaks
added flashlight mods
added some other small tweak see git for full list.
v1
initial release
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Major Credit for this project are of klquicksall! Thanks for The Beer ​
CREDITS:
To see the credits and developers that are workin on this kernel see the GIT
HERE - Kernel Source
Definitions and Terms you need to know​
Linux Android Kernel
Android's kernel is based on the Linux kernel and has further architecture changes by Google outside the typical Linux kernel development cycle.[57] Android does not have a native X Window System nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing Linux applications or libraries to Android.[58]
Certain features that Google contributed back to the Linux kernel, notably a power management feature called wakelocks, were rejected by mainline kernel developers, partly because kernel maintainers felt that Google did not show any intent to maintain their own code.[59][60][61] Even though Google announced in April 2010 that they would hire two employees to work with the Linux kernel community,[62] Greg Kroah-Hartman, the current Linux kernel maintainer for the -stable branch, said in December 2010 that he was concerned that Google was no longer trying to get their code changes included in mainstream Linux.[60] Some Google Android developers hinted that "the Android team was getting fed up with the process", because they were a small team and had more urgent work to do on Android.[63]
However, in September 2010, Linux kernel developer Rafael J. Wysocki added a patch that improved the mainline Linux wakeup events framework. He said that Android device drivers that use wakelocks can now be easily merged into mainline Linux, but that Android's opportunistic suspend features should not be included in the mainline kernel.[64][65] In 2011 Linus Torvalds said that "eventually Android and Linux would come back to a common kernel, but it will probably not be for four to five years".[66]
In December 2011, Greg Kroah-Hartman announced the start of the Android Mainlining Project, which aims to put some Android drivers, patches and features back into the Linux kernel, starting in Linux 3.3.[67] further integration being expected for Linux Kernel 3.4.[68]
​
CIFS
(Common Internet File System) The file sharing protocol used in Windows. It evolved out of the SMB (Server Message Block) protocol in DOS, which is why the terms CIFS/SMB and SMB/CIFS are commonly used. The word "Internet" in CIFS does not refer to the global Internet but to generic internetworking. The term was coined in the 1996 time frame when Microsoft submitted CIFS to the IETF and before the global Internet had become mainstream. See file sharing protocol, SMB and Samba.
NLS UTF-8
UTF-8 allows you to work in a standards-compliant and internationally accepted multilingual environment, with a comparatively low data redundancy. UTF-8 is the preferred way for transmitting non-ASCII characters over the Internet, through Email, IRC or almost any other medium. Despite this, many people regard UTF-8 in online communication as abusive. It is always best to be aware of the attitude towards UTF-8 in a specific channel, mailing list or Usenet group before using non-ASCII UTF-8.
TUN
This allows you to access an openVPN network using your android device.
Kineto gan
this driver allows you to let your android device make phone calls over VOIP network. (Tmobile currently uses this feature)
Kernel Governors​
Ondemand
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
Performance Governor
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
Powersave Governor
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
Conservative Governor
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
Userspace Governor
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
Interactive Governor
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
Lagfree
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
IO Schedulers​
Input/output (I/O) scheduling is a term used to describe the method computer
operating systems decide the order that block I/O operations will be submitted
to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.
I/O schedulers can have many purposes depending on the goal of the I/O
scheduler, some common goals are:
- To minimize time wasted by hard disk seeks.
- To prioritize a certain processes' I/O requests.
- To give a share of the disk bandwidth to each running process.
- To guarantee that certain requests will be issued before a particular deadline.
NOOP
The NOOP scheduler inserts all incoming I/O requests into a simple, unordered
FIFO queue and implements request merging.
The scheduler assumes I/O performance optimization will be handled at some
other layer of the I/O hierarchy; e.g., at the block device; by an intelligent HBA
such as a Serial Attached SCSI (SAS) RAID controller or by an externally
attached controller such as a storage subsystem accessed through a switched
Storage Area Network).
NOOP scheduler is best used with solid state devices such as flash memory
or in general with devices that do not depend on mechanical movement to
access data (meaning typical "hard disk" drive technology consisting of seek
time primarily, plus rotational latency). Such non-mechanical devices do not
require re-ordering of multiple I/O requests, a technique that groups together
I/O requests that are physically close together on the disk, thereby reducing
average seek time and the variability of I/O service time.
CFQ
CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the
Linux kernel which was written in 2003 by Jens Axboe.
CFQ works by placing synchronous requests submitted by processes into
a number of per-process queues and then allocating timeslices for each of the
queues to access the disk. The length of the time slice and the number of
requests a queue is allowed to submit depends on the IO priority of the given
process. Asynchronous requests for all processes are batched together in fewer
queues, one per priority. While CFQ does not do explicit anticipatory IO
scheduling, it achieves the same effect of having good aggregate throughput for
the system as a whole, by allowing a process queue to idle at the end of
synchronous IO thereby "anticipating" further close IO from that process. It can
be considered a natural extension of granting IO time slices to a process.
DEADLINE
The goal of the Deadline scheduler is to attempt to guarantee a start service
time for a request. It does that by imposing a deadline on all I/O operations
to prevent starvation of requests. It also maintains two deadline queues, in
addition to the sorted queues (both read and write). Deadline queues are basically
sorted by their deadline (the expiration time), while the sorted queues are sorted
by the sector number.
Before serving the next request, the Deadline scheduler decides which queue to
use. Read queues are given a higher priority, because processes usually block
on read operations. Next, the Deadline scheduler checks if the first request in the
deadline queue has expired. Otherwise, the scheduler serves a batch of requests
from the sorted queue. In both cases, the scheduler also serves a batch of requests
following the chosen request in the sorted queue.
VR
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. May be best for benchmarking because at the peak of it's 'form' VR performs best. Performance fluctuation results in below-average performance at times. Least reliable/most unstable.
Old Rcmix Kernels for Download​
RCMIX SENSATION ICS V1
RCMIX SENSATION ICS V2
RCMIX SENSATION ICS V3
RCMIX SENSATION ICS V4.1
RCMIX SENSATION ICS V4.2
RCMIX SENSATION ICS 4.3
RCMIX SENSATION ICS 4.3 STOCK GPU
RCMIX SENSATION ICS 5.0.1
RCMIX SENSATION ICS 5.2
RCMIX SENSATION ICS 5.1
RCMIX SENSATION ICS 5.1 STOCK GPU
RCMIX SENSATION ICS 5.0.1 STOCK GPU
RCMIX SENSATION 5.3
RCMIX SENSATION 5.3 STOCK GPU
5.3 with sense 3.6 fixes in the zip
http://d-h.st/JYS
Nice..was looking for rcmix kernel.
Thank you
Edit. Moderator please delete this post for the OP
My apology
Sent from my HTC Sensation 4G using Tapatalk 2 Beta-2
epsix said:
Nice..was looking for rcmix kernel.
Thank you
Edit. Moderator please delete this post for the OP
My apology
Sent from my HTC Sensation 4G using Tapatalk 2 Beta-2
Click to expand...
Click to collapse
No need to delete. I only need the first 3 posts.
Thanks for the support.
nice work. looks good. will there be a version with no gpu oc? cpu we can control but gpu we cant. and mine tends to overheat with gpu oc kernels. also, what is the recommended cpu gov? thanks
walkinhotdog said:
nice work. looks good. will there be a version with no gpu oc? cpu we can control but gpu we cant. and mine tends to overheat with gpu oc kernels. also, what is the recommended cpu gov? thanks
Click to expand...
Click to collapse
That wouldn't be out of the question for a stock gpu. I use On demand. ICS On demand uses a two stage system to regulate the frequencies. It's not like the one stage gingerbread gov. So for I find On demand or the new ICS interactive gov to be the best. The ICS Interactive gov seems to be much better.
woah, recently there are so many wonderful kernels...
Hi there, just try the v4.3 in baad's B12 ROM, but it's strange that I cannot access the file in SD card. No music and phot files can be accessed. But after I flash to other kernel, the files are back. FYI. Any idea ?
chihliouma said:
Hi there, just try the v4.3 in baad's B12 ROM, but it's strange that I cannot access the file in SD card. No music and phot files can be accessed. But after I flash to other kernel, the files are back. FYI. Any idea ?
Click to expand...
Click to collapse
Weird I can access all my music and sdcard just fine. What app are you using to access your ad card.
Sent from my HTC Sensation Z710e using xda premium
chihliouma said:
Hi there, just try the v4.3 in baad's B12 ROM, but it's strange that I cannot access the file in SD card. No music and phot files can be accessed. But after I flash to other kernel, the files are back. FYI. Any idea ?
Click to expand...
Click to collapse
Works fine for me here, using root explorer to check. What app are you using?
Sent from my HTC Sensation Z710e using xda premium
Ishouldntbehere: testing your kernel for T-Mobile WiFi calling will let you know how stable WiFi calling is
Sent from my HTC Sensation Z710e using xda premium
do u even have klquicksall's permission to post this here?
Video???
Sorry to say but i am still experiencing lag after video
Link down.
Please fix.
shiningarmor said:
do u even have klquicksall's permission to post this here?
Click to expand...
Click to collapse
Well were close so its not a problem.
Sent from my HTC Sensation Z710e using xda premium
shiningarmor said:
do u even have klquicksall's permission to post this here?
Click to expand...
Click to collapse
He is a part of out team so no worries so is klquicksall so all together
Sent from my HTC Sensation Z710e using xda premium
d3vilskid said:
Ishouldntbehere: testing your kernel for T-Mobile WiFi calling will let you know how stable WiFi calling is
Sent from my HTC Sensation Z710e using xda premium
Click to expand...
Click to collapse
Nice let me know how it goes
Sent from my HTC Sensation Z710e using xda premium
capychimp said:
He is a part of out team so no worries so is klquicksall so all together
Sent from my HTC Sensation Z710e using xda premium
Click to expand...
Click to collapse
Nice work with the kernel
my phone is back alive too, i'm so happy hehehe
now i need to flash some stuff to update my self was hard times without the phone, 4 weeks is a loooong time
laserman123 said:
Link down.
Please fix.
Click to expand...
Click to collapse
Should be fine now
Sent from my HTC Sensation Z710e using xda premium

rk3188[x7010] - Performance Tweaks, Test Journals, Learning diary, and custom ROM nV 1.03 for x7010

rk3188[x7010] - Performance Tweaks, Test Journals, Learning diary, and custom ROM nV 1.03 for x7010
First of all, I wanted to say thanks to LEOLAS of FREAKTAB for all the knowledge I've learned and also for OMA for making his roms PUBLICLY ACCESSIBLE AND FREE!!
PLEASE DO NOT COPY/PAST MY/THIS ARTICLE/POST Without Giving the right credit/Link to this post and XDA Forum too!!!!
I'm A WRITER AND I Dont like PLAGIARISM !!!
although It is fine for me if you will rewrite it in your own words
Oh I will introduce my self first, I am From the Country of [>--] Philippines, though very few developer came from our country, this is because of the LACK of INTEREST / PASSION of most of my countrymen.
I am th3f33, Pronounced as DAFFY or read as The Fee, ayt? xD The real name is Demi francisco, I am a Professional DESKTOP and Laptop Tech, and was used to be my previous work / job. Now I am currently focused on Web Developing and Programming (HTML,CSS,PHP,MySQL,JAVASCRIPT,ETC) that's why I am pretty familiar in the way the ANDROID Language goes (C+,Perl,PHyton,java Ayt?). I AM THE MAD PROGRAMMER!! lol XD (Just like hohouin kyouma).
For the sample/preview of my first cooked rom performance, Here is a YOUTUBE Video for it, stress test in HD Games.... http://www.youtube.com/watch?v=mm1ewtDljuk&feature=youtu.be
Vid is 14 minutes long, it would be better to check this first at least the first 5 minutes, and if you are interested, then you can continue to read.
So the device is:
SKYWORTH SKYPAD X7010
(quickly phased out on Skyworth MAIN Upon the release of x7011)
Full SPECS: (Stock)
Rockchip 3188 Quad Core Processore (28nm, 512kb l2 cache, 1.6ghz)
2GB Hynix DDR3 SDRAM 1600(h5tq4g8) Clocked @ 300mhz idle, 400mhz 1.2v
Hynix 8GB Internal Nand FLASH h27ucg8t2atr
Mali 400MP4 GPU @ 600mhz
Wifi and BT By mediatek (MT5931 and MT6622BT)
UP TO 64GB micro sd support
USB OTG
NTFS SUPPORT
HDMI SOCKET
7", 1280 x800 resolution
Audio is Realtek RT3261
NO GPS, No other sensor except accelerometer
Stock OS JB 4.1.1 (Ported/unperfected rom, missing libs, cannot run NBA2k13 on stock rom 4.1 due to the missing lib)
Facebook Group for my Custom Rom with Links to Download - please join my group, im CREATING an Army XD
https://www.facebook.com/groups/187854081403188/
NV v1.03 Custom rom By: Th3f33 (yey its me!~)
Features:
Rooted
Tweaked for MAXIMUM Performance for the price of a little battery timespan.
ANDROID SDK 2.0 4.2.2 (4.3) Based
Incomplete UI (Kitkat Based/Transparency), Not calibrated very well...
Internal storage(system) increased from 1GB to 2GB while internal SD decreased to 4.4gb
Anti-Aliasing x4 Unlocked on Developer Options
Comes with the CWM Recovery (Thanks again to LEOLAS!!! YOU ROCK!! HAPPY NEW YEAR)
Faster Reading And Writing Speed
Nand Flash and RAM Tweaks
GPU Tweaks!
99.7% Fully Functional and Error Free (As far as I tested, until Nov 2013, Im not sure right now, but may not have any problems updating google apps at all)
Bloatware Removed / Reduced
Added Apps:
Root Explorer
Jota+
Android Kitkat 4.4's Office
Android Kitkat 4.4's Google Launcher
Chrome
Rebooter App
PPSSPP (PSP Emulator)
Viper4Android Sound Effects
DOWNLOAD LINK IS SOMEWHERE IN THE MIDDLE of the whole article...
if there are some that i had forgot to mention, please do remind me XD
Instructions.
1.Install Adb Drivers after downloading the zip,
2.enable usb debugging or enter the bootloader mode by turning off the device, then holding both the volume button and power.
3.run the nV flasher, install drivers, if not yet in bootloader mode, reboot now by pressing the reboot on the flasher.
4.clear nandb then flash!
I AM NOT HELD RESPONSIBILITY IF IN ANY CASE YOUR DEVICE GETS BRICKED!
EXCLUSIVELY FOR Skyworth's Skypad x7010 only, but may also work on chuwi v88 [not tested]
I do provide unbricking service for a fee, but if you will read thoroughly this whole post, you will see the keywords to search for to unbrick rockchip rk30 devices!
DETAILS
I do believe that these tweaks / Performance increase / Speedup can be applied to all RK3188 devices, with the same logic / techniques can also be applied to rk3066 to maximize the performance. BUT BEWARE ON THE RAM(MEMORY) CHIP!!!!
Now here are the information on What i Modded and how to Improve the Performance
NOTE: (If the performance of my tablet on the video on youtube is the same as the performance of stock rockchip rk3188 tablets/devices, please do say it to me so that I will be able to change some Description on all of my posts across the INTERNET!! Thank you!)
so.... here is the learning diary and test journal
CHAPTER 1. Full brick at 1st week
The x7010 did not had any kind of update OTA from skyworth, and was replaced quickly by x7011. Since skyworth is a chinese company, i am not really expecting anything from them. but the sad part for me was when i bought the tablet, (About $150 converted currency) and then looked over the internet for supports such as CWM Recovery, CROM, Cyanogenmod or anything else, I FOUND NONE! Great! Not even a Copy of STOCK ROM! Which give me the idea of studying/learning the developing since i had already interested in doing so, and will also make me one of the pioneer custom developer/cooker for our device.... YEY!!... but it was not easy, IT WAS A HARSH PATH....
After my 1st week of trying, I already got a FULL BRICK ON MY DEVICE, But lucky me, im a great actor, so it ended up replaced from the store since it was still covered in the 1week replace 1 year service warranty. (I had softbricked the device by trying to flash Finless rom 1st try, then glassrom 2nd try, then i fully bricked it by flashing with no bootloader & parameter, erase nand db so that the store wont find out that it had been rooted and flashed!)
Chapter 2: Unbricking Success!
So on my 2nd chance, First thing i did was to do a ROMDUMP for backup (NO CWM YET), then I tried to create another CWM Again BUT I FAILED, Where i left it as is with no recovery but working system.... then i posted my 1st post here and in freaktab WHERE I stated that I want to learn and dont want to be spoonfed... Then after a few days, leolas tried to make the CWM!!! but I cant seem to flash it via flash_image, so I used a 1.37 rk tool, to flash the recovery, (Now i know that i messed up the partition offset of the recovery before so it doesnt really boot to recovery!). but by testing out what i understand from the forums, researched alot regarding parameter, mtd partition, the way android system boots and operates, i finally flashed the CWM Successfully on my device! so i backed up trice the device, and since i was so excited, i tried to flash a new rom again, but the excitement and an old mouse that double/triple clicks BRICKED my device by flashing it with NO PARAMETER AND BOOTLOADER, and all other are checked and the flash are already being erased.
No more bootloader mode, no more adb, not detected in PC In any way. then i found out the pin 8& 9 shorting for the nandflash unbrick method, tried it, stripped down my tablet, but i was so sleepy so it resulted in a failure. I dreamed that i will be able to revive the device by retrying it so when i woke up, the first thing i did was to do the PIN SHORTING then i plugged the usb cord, then poof,! Success! MASK ROM MODE FOUND!! then flash my romdump (Backup from cwm with tar and tar.a cannot be flashed ). Although i have one problem, the dump have the system in .tar and i need a .img, so once again, GOOGLE! kept on searching till i stumbled on a forum where an instruction of how to make a System.img flashable from update.zip. Using a Linux mint VM then plus learning basic syntax of linux, got it working ! .
Chapter 3 - BRAVERY!
This scenario made me think that NOTHING CAN STOP ME NOW! since it was the most difficult part for me, especially the unbricking part. so ill make it a little bit short, i flashed many roms, and recorded the differences for every rom,(ALL ROM ARE FOR RK3188, m9, u8gt,mk908, t428, glassrom, m9, etc), some rom displays, some don't, some boots, some doesn't. I also learned to logcat, read logcats, read and debug using dmesg. the rom that had been most compatible for my device is the chuwi rom v88 by oma (Yeah it rocks!) with working wifi, bluetooth, and everything else except for 3 problems, Inverted Camera, Accelerometer not working and NO SOUND! NO AUDIO! WAAAAA but was able to use it still, and checked the performance. run some benchmarks, played some games, although no sound, it was fine, with a few random lagging.... still, i continued to study it and modifying.
Next part was the System UI - framework.res and baksmaling and modfying apks, mostly for the User interface, and those were pretty easy since you can use the TRIAL AND ERROR Technique!. I have already the idea for the configs in build.prop, and just did some trial and error. By doing all of this, continuously, i am learning different syntax & commands too using adb and terminal emulator. so in the end, i maximized the performance of the rom, without touching the kernel. But i still notices the lag, one scenario is this, Fresh boot, Playing NBA2k14, then by some reason, after the camera zoom, the game slows down or get a little lag, about 22 - 28 fps, in order to get back to the max fps gaming, sometime i touch the notification area, sometime pause - resume. and when i am on max fps on any game, then accidentally touched the home / recent button, when i return to the app, it gets so lag! and when playing simultaneous game, it gets really lag.
Start the tweaking
I know this symptom, Applying my knowledge & experience in desktops. I had declared to myself that THIS IS THE EFFECT OF A BOTTLENECK! (Unbalanced specs & performance) or Memory bus width too low therefore bandwidth limits the overall performance so i checked the OC of the device, then found out that it was not overclockable thru software.
Google is my friend, and found out that i need to compile my own kernel that enables the Clock adjustment of the device to exceed the 1.6ghz. I was too naive that I Underestimated RK3188's Power. my initial goal was to OC the CPU itself, but after googling hours and hours, asking my mentor on how to compile a kernel, looking for sources which was the same for our device, eventually i found none xD, then, I stumbled upon.... OVERCLOCKOMATIC / Patchomatic!! a linux app that enables patching kernel's clock settings. And i found out that it can patch ram / gpu / cpu!
Since i was An Experienced Overlclocker (Overclocking on desktop, e5400 (2.7ghz Raised to 3.15ghz), On AIR / STOCK FAN + Exhaust & intake circulation). First i did was a hand made heat spreader (To make this, you need an aluminum foil, fold it into three, with the width of about 1-1.5 inch, then cover most of it with any tape except for the part that will be connected to the target(my target is the cpu), and the other end for the receiver/outer/safe place to transfer heat.) first, my target is my procie and spread it through the sd card slot, and another one from the procie to the aluminum case on the wifi & bt (it was covered!) i moved the 1st end from the sdcard slot to the back cover later on when i realized that i might damage the sd card or the socket itself .
Then I tweaked it and tweaked it for days, checked stability, compared results.
our kernel is 3.0.36 compiled on ubuntu! Yey! at first i was running the device on 1.8ghz, then later on i reverted it back to 1.6ghz, due to heat issues that may damage the device with prolonged use and to save battery spantime too.
But not everything is about the clockspeed, especially when i checked the GPU CLOCK IS ALREADY MAXED, So what would be the cure or solution for the bottleneck....
of course, the logics of tweaking a processor or ram or gpu are the same for the desktop. SO HERE ARE THE MOST IMPORTANT THINGS THAT I LEARNED AND WILL SHARE FOR EVERYONE EVEN IF THEY ALREADY KNEW IT OR HAD IT ON THEIR DEVICE ALREADY OR DOESNT hAVE A CLUE!
Chapter 5: OVERCLOCKING? the correct term to it for me was clock correcting / clock tweaking.
This is the EXACT modification of the kernel clock and stepping on both cpu & gpu and ram on my kernel which IS INCLUDED IN MY CROM Where everyone in our country(philippines) with x7010 tried and was satisfied of the great improvement of performance. and last week, some russian had already visited our facebook group and was testing my rom already . they also shared some roms of their own, although i think they are ported too.
nV 1.03 [first Edition] by th3f33 Download Link:
http://bagongpleion.net/th3f33/nv103.rar
RAM
modifying the RAM (2g DDR3 sdram 1600mhz) to be run @800mhz like a ddr2 instead of the stock @400mhz like ddr1 thus increasing the bandwidth have a huge impact on MALI-400mp4 gpu since the Quad Core Rockchip Processor were fast enough to make up for the lost clock cycle but lacks bandwidth because of the 32 bit bus width. BEWARE! Our ram is 2gb ddr3-1600mhz, which have a normal voltage of 1.5v. Low profile sdram modules have only 1.2 / 1.3v normal running voltage. YOU WILL NEED TO MANUALLY CHECK THE SDRAM MODULES ON THE DEVICE ITSELF TO IDENTIFY What type of ram it is, is it a ddr3 sdram? ddr2? a low profile? and clock timings? Ive used google to fully identify my hynix ram specs and even tried running the RAM @ 800mhz 1.5v and no restarting / corruption issues! it just that it drains the battery really fast. for our device, the exact and sufficient Voltage for the ram to perform well @ 800mhz is around 1.3v - 1.35v although im using 1.3v only. THIS IS NOT APPLICABLE TO ALL RAM and WILL REQUIRE MOST OF THE ATTENTION, EFFORT AND TIME TO APPLY CORRECTLY AND SAFELY!
I cannot guarantee your life or you freedom !
Some Info on ram: Lower clock speed of ram have faster clock cycle (on default clocks of actual ram sticks) Higher Clock Speed of ram have slower clock cycle BUT Bigger Bandwidth.
Low Profile RAMS Uses less energy(VOLTAGE), expect a slight decrease in overall performance....
Some Rams have lower clock cycle and latency in their stock settings compared to other. This are the high profile / OC'ed version of rams..
Anonymous asked: "Why did you use ddr800 against ddr400 config for our ram?"
RK3188 is a quad core processor with 512kb (L2 cache per core i believe) running @ 1.6ghz which are ULTRA FAST and can be compared to an AMD athlon Mobile processor ! it was so fast that before that RAM Cycles to refresh, all the data have been stored in the ram had been processed already, so there was really no need for the quick cycle, PLUS The GPU Is an Onboard/SOC/bundled along with the CPU (like intel's I series and AMD A Series). Now They will need a Bigger bandwidth so the power of the cpu can be utilized more since more data (RAM IS 2gb, can store a lot of data! Really...) can be passed as the bandwidth is higher. therfore GPU have a wider data path for transferring the rendered graphics data to the cpu to process then pass back to the GPU or ram, dpending on situation, without clogging up the I/O Path.
Short Answer: Faster GPU and Read/Write speed at no cost (aside from a little energy drain for the increased voltage of ram, since the cpu can handle that load!)
Chapter 6: Cpu and GPU
CPU
Kernel patched, using rkpatchomatic / overclockomatic! (linux)
I also reduced the Clock stepping and adjust the voltage of the cpu from:
312mhz @ .9v
504mhz @ .925v
816mhz @ 1v
1008mhz @ 1.075v
1200mhz @ 1.150v
1416mhz @ 1.250v
1608mhz @ 1.350v (this may not be right, if i am not mistaken it was only 1.3v @ 1.6ghz on stock)
(6steppings)
to
504mhz @ 1v
1008mhz @ 1.115v
1416mhz @ 1.250v
1608mhz @ 1.350v
(4steppings)
AND the GPU speed increase by loading the driver module with:
insmod /system/lib/modules/mali.ko (removed mali_dvfs & mali_init_clock=133)
and also changing the GPU voltage and stepping FROM:
133mhz @ .975v
200mhz @ 1v
266mhz @ 1.025v
300mhz @ 1.050v
400mhz @ 1.100v
600mhz @ 1.250v
(6 Steppings)
To
200mhz @ 1.05v
400mhz @ 1.15v
533mhz @ 1.2v
600mhz @ 1.35v /1.3v
(4 steppings)
OR
266mhz @ 1.05v
400mhz @ 1.175v
600mhz @ 1.35v
(3 steppings)
The Steppings Reductions Resulted in a VERY VERY Fast Application Switching (Not using a multiwin rom, but able to run about 6-7 HD games with seemingly no lags on switching). BUT Additional battery power may be consumed because of higher idle values for each settings.
My theory, explanation, and strategy was.....
GPU & CPU Steppings logic are the same, while for the GPU the clock increases, so as their texture and pixel fillrate. But gpu power may not be nough @ 1.25v during heavy loads, that is why i've used the maximum allowed voltage for the gpu, and adjust most of the voltages so that the system will never be short on current especially when switching state.
Wanderer asked: "why did you reduced the steppings and what exactly is that?"
Stepping is the term I used for the clock settings / stop point, It came from intel, they use Speedstep and steppings. as you can see, Most of the time, when not playing hd games or not running so many many apps, The cpu (based on my new config) will either run fine at 500mhz, - 1ghz only. (large bandwidth maximizes the power of the quad core of rockchip). so it wont need to adjust itself to 1.4ghz unless it really needs it, and it will not revert back to 500mhz unless all apps and memory are cleared and closed. (Even if you press the recent apps, it will stay @ 1ghz and will not drop to 500mhz). When running a solo HD game, except for 2013 Q4 HD games like CoD & GTA SA, cpu will be fine @ 1ghz, when running other apps, like browser, music player, etc etc, it will be kept in memory, and the cpu will have to speed up itself so it will be stable @ 1.4ghz, when running multiple hd games, it will run @ max 1.6ghz.
The stepping settings helped the cpu to be STABLE @ certain clock during prolonged usage.
Plus, rk3188 is not a very good at clock switching / stepping adjustment. Some users of rk3188 uses a cpu tweaker and set their clock permanently to 1.6ghz right? but it consumes battery faster. I tried different numbers of steppings and clock config and this was the best result for performance. Well in reality, if you are going to overclock a desktop processor, you will disable the speedstep or clock switching feature because it consume power and energy. imagine that the processor needs to consistently monitor the cpu load and adjust it according to its needs. even a human will have a delay of a few seconds during the adjustment and calibration of the strength, the same logic applies to the processors too, plus if you will add the stress of the switching of the GPU, bugs and lags are generated, sometimes, it takes quite a while for the gpu to adjust its clock, from 133, to 200, then lags a little, adjust cpu, then gpu from 200 - 400, then suddenly you pressed the home button while playing, gpu reverts back to 133mhz which is far from the max, ew, where in my config, you start at 233, making everything seems to be so smooooooth, even if you enable AAx4 in the developer options you wouldnt notice the impact of it in performance, then you can disable hw overlay and enable gpu rendering too to maximize performance! if you want to save battery, then choose the 4 steppings on gpu, if you are a hardcore gamer on tablet, then use the 3 steppings on gpu, if you want more, replace the 400mhz config in the 3steppings with the 533 from the 4steppings.
STORAGE
I have Also increased the Speed if reading / writing in the nand flash by mounting mtd partitions with:
ro noatime nodiratime noauto_da_alloc data=writeback barrier=0 nobh
TIP {
instead of using an app to mount the android folder in external sd, you can use a terminal emulator, then this command to mount the folder from exterlan sd - internal, so you can play more games! (Note: please do create the /Android/data and /Android/obb on both internal and external SD
$ su mount -o bind /mnt/external_sd/Android /mnt/sdcard/Android
or
# mount -o bind /mnt/external_sd/Android /mnt/sdcard/Android
to remove the mount/bind
$su umount /mnt/sdcard/Android
or
# umount /mnt/sdcard/Android
The mount / bind is not permanent though, and you will need to enter the command every restart of the device.
}
end of message...
Elp Psy Congroo
XDA:DevDB Information
nV v1.03 [1st revision], a ROM for the Android General
Contributors
th3f33, th3f33
ROM OS Version: 4.2.x Jelly Bean
ROM Kernel: Linux 3.0.x
ROM Firmware Required: ANY x7010 firmware / softbricked
Based On: AOSP
Version Information
Status: Stable
Current Stable Version: v1.03
Stable Release Date: 2013-11-14
Current Beta Version: v1.00
Beta Release Date: 2013-09-09
Created 2014-01-07
Last Updated 2014-01-07
Reserved
ROM Screenshots, And Benchmarks:
Passmark Results:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Antutu:
Rom:
Reserved
about:
if there are any question, or criticism, or bugs, or anything else, feel free to post, i will entertain anyone :good:
th3f33 said:
if there are any question, or criticism, or bugs, or anything else, feel free to post, i will entertain anyone :good:
Click to expand...
Click to collapse
can you provide a version that have a default Android icon on the NavBar? [Back][Home][Switch]
Hey TH3F33! Its me Patrick! Hehehehe, nice you're already starting to spread your name and our tab, I hope this becomes successful and well known, will always have your support!
Edit: They really should make a forum for our tab.
Sent from my XT890 using Tapatalk
samplermonhar said:
can you provide a version that have a default Android icon on the NavBar? [Back][Home][Switch]
Click to expand...
Click to collapse
Yes, maybe I will do that maybe tomorrow, I just have to finish another task from my work.
The nV 1.04 will be Philippine themed
re
Jabbzz said:
Hey TH3F33! Its me Patrick! Hehehehe, nice you're already starting to spread your name and our tab, I hope this becomes successful and well known, will always have your support!
Edit: They really should make a forum for our tab.
Sent from my XT890 using Tapatalk
Click to expand...
Click to collapse
Tnx
I was already creating our own forum, just be patient, its a virtue. :good:
Why are you using xt890 ? Lol
th3f33 said:
Tnx
I was already creating our own forum, just be patient, its a virtue. :good:
Why are you using xt890 ? Lol
Click to expand...
Click to collapse
No I mean a category here in XDA..hehehe..
XT890 is my smartphone, the one I use for texting, blah2. Motorola RAZR i
Sent from my XT890 using Tapatalk
Jabbzz said:
No I mean a category here in XDA..hehehe..
XT890 is my smartphone, the one I use for texting, blah2. Motorola RAZR i
Sent from my XT890 using Tapatalk
Click to expand...
Click to collapse
we alreay got a place, check facebook group -.-
Looks like only a few skyworth users visits xda....
Sent from my x7010 using Tapatalk
Wait a moment, is there a 4.3 rockchip rom? The blobs it is using are from 4.2?
Edit: sorry, I just saw this: ANDROID SDK 2.0 4.2.2 (4.3) Based
jsevi83 said:
Wait a moment, is there a 4.3 rockchip rom? The blobs it is using are from 4.2?
Edit: sorry, I just saw this: ANDROID SDK 2.0 4.2.2 (4.3) Based
Click to expand...
Click to collapse
yep it is a 4.2.2 based on 4.3
two thumbs way up for you kabayan! I'm no coder, but I love to read and tweak usually consolidating tweaks/scripts for my myPhone Vortex.
Good thing its a fairly popular phone in India, else I would have been stuck with the stock rom.
I'm curious if your rom can be applied to the recently released tablet from Starmobile : Engage 8 quad+
It sports the same processor as your Skyworth but with 1G of RAM only, 8G internal. Been looking around and I've read through
the list of roms you've tried (PIPO, M9, GLASS) and its a good thing I found your thread. I would have risked to root and flash
my tablet with any of those roms.
I'm currently reading on rooting my tablet using this method below, however I'm now hesitant to proceed. Would you have another method that
would work? or at least give me a little more confidence of root success. Thereafter, its CWM, then flashing time! woot
http://www.slatedroid.com/topic/88850-rooting-rk3188-tablets/
btw, I've found the manufacturer of this tablet, guess Engage 8 is a rebrand of this unit.
http://www.google.com.ph/url?q=http...Q4BrZw&usg=AFQjCNEsT9Dux2uMCLEZykSB5umoY8nyOQ

[Guide] Advanced Interactive Governor Tweaks.

This guide is meant for ALL smartphones that runs the Interactive governor, copy-pasted here for better visibility. Credits goes to @soniCron for starting up the guide and @Alcolawl for further implementing it.
The Introduction
So, I tried copy-pasting the entire thread and realised it looks ugly therefore I'll rewrite it to be more simpler and straightforward.
Imagine a car with manual gears, you choose what speed is best suitable for the road conditions. Going into a curve? Best slow down. Clear straight road? Go fast so you reach the destination safely and efficiently.
That's what this guide aims to do with the Interactive governor, based on the CPU load it will choose the best and the lowest frequency to complete the task without compromising performance.
For example, if you scroll your Facebook page your CPU might clock up to the highest frequency for smooth scrolling. Now lower the frequency one step down and you may find that it's still smooth, so why isn't it choosing that instead? Don't blame the phone companies or Google, that's just a way of ensuring performance at all times. This guide will push the limits of that capability.
By default, the Interactive governor will jump from lowest speed to a "nominal" speed under load, and then scale up from that speed as load is sustained. That is lovely, but still too twitchy to provide serious efficiency and power savings. It spends most of its time at 2 or 3 clock speeds and barely hits other clock speeds that are ideal for other tasks or usage patterns.
Instead, what we want to do is configure it to handle different types of loads in different ways. A load suited for scrolling through a webpage is not the same as a load suited for downloading/processing streaming video is not the same as a load suited for snappy loading of an app is not the same as a load suited for high performance gaming. Every kind of load has different tolerances at which their minimal speed is indistinguishable from their maximal speed.
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Click to expand...
Click to collapse
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing lags or stutters. (If you have a CPU or kernel that hotplugs individual cores, multiply that clock speed by your number of cores.) Keep the 2nd CPU on the Powersave governor with the lowest frequency your kernel supports. (Or turn it off completely if hotplugging allows.)
Remember what was said about scrolling FB pages? This is it.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials.
For example, using stock voltages, the EvoLTE's msm8960 chipset clock/voltage ratios jump significantly higher from 702Mhz to 810Mhz than the ratios from 594Mhz to 702Mhz.
Imagine a staircase with steps of different heights. You climb these stairs better depending on the height of each steps, do you skip some steps if you can reach the next one easily? Or do you take one step at a time because they are too high?
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. For me, since I cannot determine the efficient clock rates, I use the nominal clock rates listed above. For the tasks I generally perform on my phone, my nominal clock rates are as follows:
Idle - 384Mhz
Page Scrolling - 600Mhz (Tested by browsing FB on Chrome browser cause they're intensive enough)
Video - 787Mhz (Same thing, watch 60fps videos on different resolutions on the Youtube app to detect stutters and lags)
App Loading - 960Mhz
High Load Processing - 1440Mhz
(Note that you must calculate the values that are optimal for your phone for best battery and performance! Each phone is different because of the ROM, kernel, background tasks, etc!)
With this done, you will want to start the fine tuning phase! Correlate the efficient clock rates with their closest nominal clock rates, similar to below:
(This section of the guide is INCOMPLETE because I do not know the clock rate voltages for the Nexus 5X. If you know these, please post in the comments and I will update the guide!)
Idle - ???Mhz efficient / 384Mhz nominal
Page Scrolling - ???Mhz efficient / 600Mhz nominal
Video - ???Mhz efficient / 787Mhz nominal
App Loading - ???Mhz efficient / 960Mhz nominal
High Load - ???Mhz efficient / 1440Mhz nominal
Now that we know what are the most efficient nominal clock rates we want to focus on and what the most optimal are for what we want to do, we will start low and scale up as necessary. It's always better to begin with underperforming and tweak the settings upward until we're satisfied with the performance of our target tasks.
In its default state, the Interactive governor has a hair trigger that will raise and lower the clock rates, which means it spends too much time at unnecessary clock speeds, wasting power, and scales down too quickly, leading to stuttering performance. We will take advantage of a seldom used feature of the Interactive governor. Specifically, that with which it determines when it is okay to scale up to each higher clock rate, on a frequency by frequency basis.
We have two primary goals: respond as quickly as possible to each load request for a lag free experience and exceed the desired clock rate for a given task as little as possible. To do this, we will instruct the Interactive governor to trigger certain clock rates in different ways depending on our expected load.
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do. I'll wait here.) However, I will explain an incredibly powerful feature of the Interactive governor that is rarely included in those summaries: multiple frequency adjustments.
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 460000:60000 600000:20000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 460Mhz. Once it has exceeded 460Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute. And if you don't know what I'm talking about when I say "highspeed_freq" then you didn't go search for the basic Interactive governor settings and read about it! Go do that before you read any further, because I will not explain the basics of this governor!)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
Find Optimal Loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be caluclated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
For the Nexus 5X, the maximal efficient loads of CPU 1 are:
384000:75
460000:69
600000:80
672000:76
787000:81
864000:81
960000:69
1248000:78
For the Nexus 5X, the minimal efficient loads of CPU 1 are:
384000:0
460000:19
600000:30
672000:12
787000:17
864000:9
960000:11
1248000:30
1440000:15
For the Nexus 5X, the maximal efficient loads of CPU 2 are:
384000:72
480000:68
633000:74
768000:80
864000:81
960000:69
1248000:83
1344000:84
1440000:84
1536000:84
1632000:86
1689000:83
For the Nexus 5X, the minimal efficient loads of CPU 2 are:
384000:0
480000:25
633000:32
768000:21
864000:13
960000:11
1248000:30
1344000:8
1440000:7
1536000:7
1632000:6
1689000:3
1824000:8
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
Well, we had put some values into target_loads earlier, but those values weren't arbitrary. See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
But What About That 2nd CPU?!
So we've all but ignored the 2nd CPU. The reason? It's a horribly inefficient processor designed for high load tasks that generally don't come into play during normal usage patterns. It's good for gaming and image processing, but not for most moderate tasks a user might employ.
But it is good for one thing that all users do pretty frequently... loading and switching apps.
Fortunately, at least for the Nexus 5X, the system is pretty smart about when to employ the power of this inefficient 2nd CPU. So it's generally kept at bay most of the time. What we want is to configure it to be our burst processor–we want it to come into play spontaneously and quickly during tasks that necessitate immediate high loads, like loading and switching apps. To do this, we will ignore all but 3 frequencies:
384Mhz
1248Mhz
1824Mhz
In this case, we configure it just as we did with CPU 1, but only worry about keeping it idle as much as possible, allow it to jump to 1824Mhz immediately when needed, and encourage it to fall back to 1248Mhz if a sustained load is needed.
These values are ideal for the Nexus 5X, so if you have a different phone, choose the lowest clock rate, highest clock rate, and median efficient clock rate, using the instructions previously.
For the Nexus 5X, we'll jump straight to...
The Money Shot: Part Deux
If you are using a Nexus 5X, use the following Interactive governor settings for CPU 2. ("big"–the one with 2 cores)
(If you are using a phone other than a Nexus 5X, you must read the above sections and replace the frequencies with your own efficient clock rates!)
above_highspeed_delay - 20000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1824000
min_sample_time - 20000
target_loads - 98 480000:25 633000:32 768000:21 864000:13 960000:11 1248000:95 1344000:8 1440000:7 1536000:7 1632000:6 1689000:3 1824000:95
timer_rate - 20000
timer_slack - 80000
Click to expand...
Click to collapse
SO there you go, that's the gist of it. I got some smaller examples written up later so hopefully it's more understandable.
"I'm Too Lazy To Read All That! WHAT DO I NEED TO DO?!?!"
If you own a Nexus 5X or 6P, install the ElementalX Kernel and the EX Kernel Manager. (Yes, it works in other kernels, but you're on your own regarding how to set the values. Other kernel editors, such as Kernel Adiutor, are currently buggy and problematic, so your mileage may vary. And if you have another device, you must follow the instructions in this post to derive your own values.)
UPDATE: EX Kernel Manager now supports governor profiles and most currently published profiles are distributed with the manager. To access: EXKM> CPU> Governor options> Load, then select the profile you wish to try! Many thanks to @flar2 for providing native support!
ALPHAS – USE AT YOUR OWN RISK!! (Actually, we really like "GostPepper". Try it out. It's spicy! And don't worry–it won't break anything!)
GlassFish (For most devices!) - High battery savings with buttery smooth interface!
HawkTail (6P) - An advanced, modern profile that is both battery efficient and highly performant! All users are urged to check out HawkTail!
Butterfly - A culmination of all strategies, provides smoothest performance of all currently published settings, though battery savings are a little more modest. Excellent for light and moderate users; heavy/marathon users might want to check out a different setting profile.
GhostPepper (6P) - Uses a quantized, frequency-aligned parametric curve to influence low core clock rates while providing extremely smooth transitions from each clock rate and exceptional battery life. The current favorite, albeit not very well tested so far. HIGHLY RECOMMENDED
SilverFish - Effectively eliminates "hispeed_freq" so perceptive scrolling performance is increased, giving the illusion of excellent performance while providing great battery life. Some users experience problems with performance while multitasking--NOT RECOMMENDED FOR EVERYONE. Light users should enjoy this very much, however.
MadDog - The first major departure from the core strategy. Very well tested, extremely stable, and HIGHLY RECOMMENDED if you aren't fully satisfied with v2.0 settings. This is on the table to be the next stable v3.0, so rest assured you can't go wrong with this one!
DrunkSauce - Supreme UI fluidity coupled with excellent active and idle battery drain. Idle Drain was consistently measured to be ~1%. And while I don't rely on SOT figures that people constantly throw around, active drain spanned from 15-20%/hr depending on usage. YMMV. And as always, flawless audio playback for you audiophiles and ARISE users out there.
Those are the ones compiled for now, please remember that these are all up to the users' preference. It will improve YOUR own SOT, not straight up 8 hours on every device. You can copy off the profiles and use your own device frequency and target loads, use an app like Kernel Auditor to help edit them. It works for stock and custom roms too.
Extra credits:
Thanks also to:
Every developer who has seen this guide, modified it, and implemented it.
All the members who contributed and argued about the inner workings of this guide, your constructive feedback is amazing and helped fine-tune future profiles.
To the poisonous and toxic trash member(s) of a certain thread for their lack of help and elitist behaviour. Their embarrassing attitude helps open our eyes to the dos and don'ts of internet manners.
This is for calculating target loads.
Let me give you an example from my Note 1:
My clock rates are (in MHz): 200, 500, 800, 1000, 1200, 1400
Their voltages are (in V): 950, 950, 1050, 1125, 1225, 1300
If I were to plot the differences in voltage, it would appear like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
From the graph, 500MHz to 800MHz has a huge difference in voltage increase compared to 1000MHz to 1200Mhz. That frequency BEFORE the huge jump is the efficient clock rate: 500MHz and 1000MHz.
So, the nominal clock rate on the other hand is the minimum frequency you can use to complete a task (such as watching videos, loading apps, page scrolling). In this case, mine are: 200MHz, 800MHz, 1000MHz
Now, we just calculate (from the first post) the minimal efficient loads for efficient clock rate and maximal efficient loads for nominal clock rate.
That means my target loads will be:
500: 60
800: 72
1000: 75
1200: 17
I skipped the calculations but this will be what it looks like from there. Someone pls do let me know if I made a mistake, as it does tend to confuse people with other devices.
Nominal clock rate: Maximal load
Efficient clock rate: Minimal load
Edit: Those are for the target loads, for the rest of the settings I'll use the profiles'.
Eh, mmight as well reserve this too
Nice looking guide, about to read
wtf,you just copy pasted in the end
Nice beginning, but half is missing, and you are referencing things that haven't been done before

[Guide][CPU Tweak] Advance Interactive Governor Tweak for Whyred

Hi Guys, this is a continuation from initial discussion (and my promise) on InsigniuX kernel thread HERE
UPDATE 1 : After further testing, incorporate input boost to CPU 1 and 5 actually help the performance without affecting battery, as long as we set it within the optimal frequency. I also put fine tuning in hispeed_delay value, please use latest Profile File if you are using PRESET, or check the new values bellow if you do manual config
NOTE : If you are too lazy too read all the technical stuff, simply download the PRESET KERNEL ADIUTOR PROFILE HERE, and apply it to your Kernel Adiutor (choose "profile" from side bar, hit the (+) icon, and choose "import" and choose the downloaded .json file)
as we all know and aware, we always look and try to find the most optimum configuration to achieve best battery life without sacrificing performance. And while of course Qualcomm and Xiaomi have the most talented developers in their team, sometimes the implementation between both in their mass product might left a room for improvement. And in that exact room, we as community here play our role,
so, in an attempt to get a better fluidness out of this device, without sacrificing battery life, i remember one of the guide made by @soniCron i used to stumbled upon few years ago. This Guide give a very detail insight on how to optimize the interactive governor on almost any device/any kernel/any rom (as long as you have root), and thats what i gonna try to apply to our device - if you want to check the guide yourself : HERE
so i take a look into Whyred Kernel Sources to see the voltage values being used by our processor for each frequency step. And here's the voltage/speed table in case you want to see :
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
from that table, we can see which frequencies are using most power, and where is the most jump in voltage usage happen when switching between frequency.
Higher voltage jump will cost more power, means less battery life.
in conclusion, i found few frequencies which are less favorable, which is
LITTLE CPU :
1136Mhz - step by step Speed Gain is fine, but when compared to straight jump to 1401Mhz, the Speed to Power Ratio is become less favourable
1536Mhz - Smallest Speed Gain compared to Power Usage
and i also found some which might be the best/favourite frequencies :
LITTLE & BIG CPU :
900Mhz - Best contender for base speed, as it use almost same power with 633Mhz, but with plenty of speed gain
1401Mhz - Good Speed to Power Ratio
and
1747Mhz - Good Speed to Power Ratio for BIG CPU
_____________________________________________________________________________________________________________________________________________________
Now we take into account of the minimum frequency needed to ensure smooth task (if you dont know what am talking about, read the GUIDE i mention in my opening paragraph) :fingers-crossed:
For Whyred, i've found the best frequency is as following :
Idle = 633MHz (Lowest we can go at the moment)
Scrolling = 900MHz (Use Chrome browser to scroll Facebook in desktop mode)
Video = 1401MHz (Play 1080p*60fps videos in Youtube app)
App load = 1747MHz (Can use any app really)
High load = 1843MHz (Max out just in case)
Using the formula take from soniCron guide, i tried calculate optimum CPU load (this will be used as target load config) config for each frequencies
If you want to see the formulas :
Code:
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 0.9) / next highest clock rate
For example, the maximal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(600000 * 0.9) / 672000 = 80.36% (rounded and normalized: 80)
For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - next highest clock rate / clock rate) * -1
For example, the minimal efficient load for 600Mhz on the Nexus 5X would be calculated as:
(1 - 672000 / 600000) * -1 = 12.00% (rounded and normalized: 12)
with this config, logically speaking we want to make the Governor to favour the "best" frequencies above, and minimize the usage of unfavourable freqs.
LITTLE
Code:
633Mhz : 63
900Mhz : 71
1136Mhz : 23
1401Mhz : 82
1536Mhz : 4
1612Mhz : 83
BIG
Code:
1136Mhz : 73
1401Mhz : 9
1747Mhz : 85
1843Mhz : 90
Now that we already get the optimum number, time to apply it
Use your favorite Kernel Manager, in my case, am using Kernel Adiutor, and go to CPU Config - CPU Governor Tunables and input these value (am using Hawktail base profile from soniCron thread, as it seems it work best for most of devices, and i already do trial & error with some other value like timer rate as well ) :
(LITTLE)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 0 633600:60000 902400:75000 1401600:100000
timer_rate: 80000
hispeed_freq: 902400
timer_slack: 200000
target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
min_sample_time: 35000
boost: 0
boostpulse_duration: 0
(BIG)
Code:
align_windows:1
go_hispeed_load: 95
above_hispeed_delay: 32000 1136000:60000 1401600:75000 1747200:80000
timer_rate: 60000
hispeed_freq: 1747200
timer_slack: 100000
target_loads: 98 1113600:23 1401600:9 1747200:85 1804200:94
min_sample_time: 20000
boost: 0
boostpulse_duration: 0
Other necessary adjustment :
Boost : ON For CPU 1 at 902400 and CPU 5 at 1401600 both for 100ms
Min Big CPU Hot Plug : 0
Disable all Toggle in Thermal Section
Run Terminal and command :
Code:
su
stop perfd
or Install this MAGISK MODULE to disable Stock Thermal & Hotplug Control (Courtesy of @Mr.Nguyen0504)
Now you can test it. Do full charge and use it normally, see whether you can see the improvement or not,
be mind that this config is not really adjusted towards battery life, but rather overall fluidness/performance, yet without sacrificing too much power
Hopefully it helps you as it seems to help me (you can expect no less than 7-8Hrs SoT, am quite heavy user myself, with 2 WhatsApp account and 1 LINE account constantly active. YouTube & Gaming at least hour/day as well). Discussion is more than welcome here, as these are considered an initial calculations that still yet to furtherly fine tuned for our CPU.
Thanks mate, was waiting for this.
Initial thoughts = project butter:good:
xdarkstar said:
Thanks mate, was waiting for this.
Click to expand...
Click to collapse
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
otonieru said:
please let me know the experience, i only test it with my personal preferences, so your desire with your device may vary
but i think it shouldnt be that far
Click to expand...
Click to collapse
Excellent guide as well. Will test parameters over the weekend.
I will test this
mxilil said:
I will test this
Click to expand...
Click to collapse
yes please,
in the meantime, i also testing another config with input boost enabled, and some fine adjustment to hispeed_delay,
if it turn out to be better, i might create 2nd preset, along with custom control to disable BCL and Perfd. So we do not need to type it in terminal manually after reboot and let adiutor do that.
otonieru said:
Run Terminal and command :
Code:
su
stop perfd
Click to expand...
Click to collapse
I think "stop perf-hal-1-0" is the proper command.
@otonieru Great thread, very nice presentation of the matter with just the right info and setup example.
I have followed the same tutorial for my previous device but ended up using the tunables from my ROM maintainer as I never managed to calculate it properly, probably because I overlooked the voltage jumps.
Now, I wonder whether the minimum freqs of 300mhz for both clusters would help in battery life gains, taking into account the proper target loads are set for both and "timer_rate" and "min_sample_time" are tuned to make CPU ramp up quickly to avoid lags and stutters.
Logically, voltage is lower for lower frequencies, but in this case, 300mhz and 633mhz might be the same on little cluster or the voltage jump might be insignificant, but the voltage jump on big cluster might be bigger. And since the big cluster is on minimum frequency most of the time we might see some gains there.
Can you check the sources of some kernels with full range of frequencies (not the ones who have undervolt applied) and see the voltage tables?
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
Code:
[init.svc.perfd]: [running]
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Cirra92 said:
Where is perfd located, or the file that contains the values for perfd daemon? It seems that the terminal command to disable it doesn't work, on any load except standby it still hits 1612mhz on little cluster, which is extremely annoying.
EDIT: There is no line about running state of perfd like this:
There is only a line pointing at the presence of perf daemon I believe. Does this mean that perfd is not running on my system at all, so the "stop perfd" command doesn't do anything?
EDIT2: My bad people, I've set target loads for 1536 and 1612 to 4 and 8 respectively, by missing another number. Now I've set them to 98 and 100 as it was set on my previous device for two of the highest CPU steps, now the use of freqs seems much better and the device performs nice.
Click to expand...
Click to collapse
Actually, i didnt include 300Mhz in my calculation because i try to check various whyred kernel source, and found that not too many of them make the 300Mhz available to beanually selected, but i do check the voltage used by 300Mhz and its saving is almost neglectible,
and as i do this tweak based on my current kernel set up (InsigniuX), i do it with 633 as base.
as for 1612 being used much,
i found that there's probably a bug in our device kernel code that make cpu sometimes lock in its highest frequency (1804 & 1612), it only happen after you restart the phone, (and it happen with most kernel out there, so its not literally the dev mistake, more like xiaomi messed up some codes)
the fix for now is by opening adiutor, ensuring that the freq not locked up. If its locked, change it back manually to 633 and 1133 (for small and big respectively), i found that it manage to stay until another reboot.
my cpu usage is as how i expected from my target load. so i think it play nicely for now.
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
I am still on first charge since tweaking the kernel. So far it seems that the battery life is going to be the same, but it feels to me that everything is just a bit faster now, app opening and loading times are shorter and a bit smoother, might be a placebo, but it works nice.
One thing you should fix in main post, your target load for 1612 mhz in little cluster is set to 8, but in calculations it is 83, I suppose you missed the 3 when you wrote the tunables
I am going to update the settings you added after it falls to 20% and I recharge it.
One more thing, if I use the Magisk module for thermal and hotplug (or simply turn off the Core control in Kernel manager) does it mean that the cores will go offline if there is no load?
I remember having different hotplug solutions on SD801 devices which actually turned off 3 cores and left only one to do basic functions in deep sleep, or turn on 2 of them when there is low load on the CPU.
@Cirra92 ah right ! i might hit the backspace accidently, LoL
about hotplug, honestly am still testing it myself to figure whether the config work as intended or not, since the behaviour of this chipset it quite different. And since oreo its a bit harder to really track the cpu activities, we need to run an app to see the activities, but the app itself is giving load to cpu, thus the reading might not actually accurate.
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
blackbellz said:
1. Can you repost the voltage table image again? i can't see or is it missing? i really need this voltage info table, I've been playing with kernel tweaks this last few weeks.
2. On your 1st post,little cpu target load arguments are as follows : target_loads: 70 633600:63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
I don't think its the right setup. the first argument is target load which is 70, is affecting all freq starting from lowest to the highest (if there are no more arguments). but on 2nd argument you write 633600:63 (assuming 633600 is our lowest freq) then the first target load (70) has no effect. cpu target load for lowest freq (633Mhz) will be 63%, at 902Mhz the target load max is 71% and so on. And your screenshot shows the setup behavior. It idles at 633 then only spend small amount of time at 902 and 1401 and go right at the max freq for almost one and a half hours of total. If you want 633600 max target load 63% then the setup as follow :
target_loads: 63 92400:71 1113600:23 1401600:82 1536600:4 1612800:83
It means max target load from the lowest freq (633Mhz) will be 63% until below 902400. at 902400 max target load is 71% until below 1113600... and so on.
CMIIW
Click to expand...
Click to collapse
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
crap, i cant even attach 2 picture in one post
otonieru said:
After further testing, i update the config to incorporate boost & better tuning of hispeed_delay for each frequencies,
please check main post
Click to expand...
Click to collapse
Can you add an image of the voltage table? The original image is not visible^^
otonieru said:
i still can see the table, probably the connection from xda server is not good, its kinda patchy nowaday,
and btw, maybe you are right about the target loads. Although as i mentioned as well, that this config is lean more towards percormance, so its kinda intended from my side. But am still testing some other value as well, and i gonna try with your value as well.
as for now, my current set up is quite satisfy me.
Click to expand...
Click to collapse
i tought this was towards battery but still keeping performance.
Try it or die said:
Can you add an image of the voltage table? The original image is not visible^^
Click to expand...
Click to collapse
Yup, it's not visible. But OP said its visible to him...
raptorddd said:
i tought this was towards battery but still keeping performance.
Click to expand...
Click to collapse
no, its the other way round as i wrote in my main post, LoL. But i guess 9-10Hrs SoT is more thwn enough wasnt it ?

Categories

Resources