yashsingh1/xdaforums huggingface dataset:
[OnePlus 3 & 3T Cross Device Development] vinax89:
Please test which schedtune values are better for you. Render recommended these values but individual idiosyncrasies exist so your mileage may vary:

/dev/stune/background/schedtune.boost 0

/dev/stune/foreground/schedtune.boost 5

/dev/stune/top-app/schedtune.boost 15

/dev/stune/schedtune.boost 10

Test for at least 48 hours with normal usage and post here.

We can all learn from helping each other.
[OnePlus 3 & 3T Cross Device Development] :
And how do I change it?

Edit:never mind got it will report
[OnePlus 3 & 3T Cross Device Development] liam_davenport:
My battery life from second charge

No root or bs apps like Facebook etc Only using XDA app, Stock rom + kernel
[OnePlus 3 & 3T Cross Device Development] vinax89:
Pretty good there! Thanks for the report! :good:
[OnePlus 3 & 3T Cross Device Development] liam_davenport:
Android system is at 13% Guessing that's a OOS problem
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
global boosting is not recommended (the last line)

and note: the higher the schedtune.boost values, the longer the delay to enter deep sleep.

---------- Post added at 01:48 PM ---------- Previous post was at 01:47 PM ----------

NOTE: Android System and Android OS being your top battery consumers is not necessarily a bad thing at all.
[OnePlus 3 & 3T Cross Device Development] :
So what value of global boost u recommend?
[OnePlus 3 & 3T Cross Device Development] vinax89:
DISCLAIMER: Seeking constructive input

If I remember correctly, Pixel has this configuration in v1.0:

Top-app: spread policy + SchedTune boost of 10%

That is if I remember correctly. Render's original value was set to "12" (post number

#365)

but he revised it to "10" (post number

#413

) to increase efficiency (I guess so,) since the higher the N value, the least likely it will return to idle to an x value of time. Now, I don't really know what N value is most efficient to our device OP3 since we just ported this from the Pixel EAS (v1.0) and the subsequent update (v1.2). So we must first determine what is the most efficient N value and start from there (+/- y(N) where y would be any real number.) That would mean testing Positive and Negative boost values and their respective efficiency values (power draw vs frequency*duration again,) where CPU Power Draw = C x F x V^2 (where C=capacitance, F=frequency, and V^2=Volts squared.)

Now,

I am no expert in this field and want to know from you

[MENTION=5060769]Mostafa Wael[/MENTION] since you and et. al. pioneered the AKT profile values and have more knowledge in this particular field and subject since both you and Asiier have established the most efficient values using the Interactive governor. :good:

Hopefully you can tell us more

regarding your tests and results so that we can have a starting point in testing the N value. :)

Also note that the complete EAS framework is still not fully implemented and we are just at the tip of the efficiency iceberg and things will only get better as more of the code is ported and the schedtune value is

defined

and

fine-tuned to our device.

Render will most likely tell us his findings and his input regarding this matter as this is his port. :fingers-crossed:

---------- Post added at 01:48 PM ---------- Previous post was at 01:47 PM ----------

NOTE: Android System and Android OS being your top battery consumers is not necessarily a bad thing at all.

Yes, you are correct. Most users view Android System and OS top drain as a bad thing and this is a misconception. If these are at the top in your drain list, most likely there are several scenarios as what users have reported over the months in this forum:

1. You are a light user.

2. Your apps are efficient.

3. You have not used your phone that much.

4. You have wakelocks here and there that need controlling.

5. You have dirty flashed and/or have messed up somewhere.

6. You have installed an unstable system modification (unstable version of SuperSU.)

7. Your modem version is acting up on terrible signal.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
It is really hard for me to read with one eye, but I have to tell you i already have some settings changed here, considering some negative values as well.
[OnePlus 3 & 3T Cross Device Development] vinax89:
Care to tell us these values? I am interested in finding the "Goldilocks value." Sorry for the minute font size.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Of course I do, but i have to stress some specific points.

1- this is totally experimental

2- this is not aiming for the absolute performance as I use to do with my Burnout PR profile

3- complementing the first point, this is still in testing phase, can be good and can be bad.

4- i am not a gamer

As for the Android OS/System thing, I have a hypothesis about it that I will write soon, as well as my profile of settings that I will share with you here :)

Just give me a few minutes to relax my eyes
[OnePlus 3 & 3T Cross Device Development] madsponge26:
Normal usage 34% battery jiuce remaining.
[OnePlus 3 & 3T Cross Device Development] vinax89:
Sure, rest is priority! :)

Yes these are all experimental values because we are at the bleeding tip of the edge of the android kernel realm. :D
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
About that thing of Android OS and Android System being top batterg consumers, here is my hypothesis

EAS controls the power given to each of the apps active (background, foreground, and so on), so if there are apps active sipping unnecessary power, it is massively decreased now. However, since the EAS implementation is a ROM&kernel one, the battery stats report higher battery consumption by Android OS and System. In other words, those two are EAS itself. IMO it is nothing bad at all if what I think of is right

Also I would like to remind you that this percentage shown beside each battery consumer is a relative percentage and not a total percentage.

Now onto my settings that I have been experimenting with.

NOTE: I am aiming for efficiency with the current settings, maybe even being more extreme than ever before. Tweaking for performance (a la Burnout) may come later

/dev/stune/background

> schedtune.boost = -50

/dev/stune/foreground

> schedtune.boost = -15

/dev/stune/top-app

> schedtune.boost = 13

/dev/stune

schedtune.prefer_idle = 1 (untouched)

I/O scheduler = deadline

Read ahead buffer size = 256 KB

Speed and smoothness is very comparable to HMP, battery life is very nice as well with this setup. Here you are the stats:

54% drained with 3 hours 16 minutes SOT, total time of usage is 14 hrs 26 minutes

Flat line overnight (ZERO idle drain)

Usage included brutal multitasking and constant typing, as well as keeping the brightness at ~40%. Apps used are: XDA Labs, Slack, WhatsApp, Chrome (for facebook checking. Scrolling was top-notch btw), YouTube, Telegram and Gmail. Auto sync was on.

ROM is FreedomOS 2.3

Kernel is [MENTION=5438598]RenderBroken[/MENTION] Final EAS build.

P.S. no weird issues with the big cluster here. Also I have Android System and Android OS as my highest two in the battery stats list.
[OnePlus 3 & 3T Cross Device Development] vinax89:
I see that facebook drained the most(in regards to time of use. Have you looked onto replacing Facebook with other more efficient apps? I think you will have more screen on time than that. :good:
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Also a reason for deeming them experimental is because EAS is still a new animal in the arena. We are yet to understand how it behaves and how does each value impact the user experience. Heck even verifying if it is working as intended or not is tricky on its own! You see, a lot of things to read and experiment with :)
[OnePlus 3 & 3T Cross Device Development] vinax89:
Nice! This is what I was expecting since positive values seemed too much for our device for the current implementation. Maybe when more of the code is ported can we look into positive values since there is still a lot to do.

It would be great if we can also define and manipulate the priority of a certain workload to EAS to initiate efficient and optimal load balance. It would be more suited to consumer experience optimization since EAS relies on the quantification of energy usage per workload as well as power-performance tuning. But knowing EAS, it would still make decisions based on energy cost to workload ratio to dictate frequency.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Would like to point out that:

1- the whole decision of what task receives how much power and the energy cost and all depends on the energy model used

2- there are some framework commits that we are missing to further improve the efficiency and make the UX smoother. Render to verify.

And the values i provided seem to work well so far
[OnePlus 3 & 3T Cross Device Development] vinax89:
1. Yes, but that energy model would be dependent on our device and the scheduler policies created in regards to that. We still have a very little idea regarding this.

2. Yes, Render stated that the implementation is still a WIP so it will improve over time.

Regarding #1, can we modify the energy model and scheduler policies to fit our device in the first place? From what I read, the is an upcoming different approach being developed by ARM and Linaro engineers.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Well we can change the energy model used in EAS i am sure. There are some other energy models available. I heard that Alucard has made an energy model specifically tuned for the LG G5
[OnePlus 3 & 3T Cross Device Development] vinax89:
Nice, then the defining values and terms must first be laid out to accommodate architectural and software idiosyncrasies. If we can have our own energy model, we can develop specific per cluster policies to optimize EAS for our device then. Task load tracking itself must be different on our system from the Pixel since we have seen some odd frequencies being used in our implementation.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Those odd frequencies are due to the fact that we have schedutil governor instead of the schedfreq governor.

Here is how schedutil works:

schedutil isn't a DVFS governor like the old schedFreq, it works like an ordinary governor but calculations are based on CPU utilisation statistics and frequency steps are custom rather than the predefined ones depending on the end result of calculations made from the governor

-ZeroInfinity

Check this link: http://www.linux-arm.org/git?p=linux-power.git;a=commit;h=9bdcb44e391da5c41b98573bf0305a0e0b1c9569
[OnePlus 3 & 3T Cross Device Development] franky14:
Apologies if I'm being a noob but could you please let us know how and where to edit these values, it'll be really helpful.

Thank you
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Use a root explorer and edit the specified files in the paths i wrote in bold ;)
[OnePlus 3 & 3T Cross Device Development] vinax89:
Yes, but our implementation of EAS doesn't follow the specific energy model and policies on Pixel, we also have a relatively new WIP implementation and also there is overutilization and sub optimal task placement being described.

Excerpt from Linaro mailing list from Joonwoo Park from CodeAurora:

"IMHO skipping EA task placement based on inner overutilized flag still

can occur suboptimal placement when there is unavoidable load imbalance

within a SD.

For example say there is a 2+2 big.Little system and CPU0 and CPU1 are

little CPUs.

All other CPUs are idle but little CPU1 has a CPU bound task which makes

little cluster's SD marked as over-utilized.

Under the such condition any new wake-up of which the task's prev_cpu is

either CPU0 or CPU1 will do non-EA placement.

As a result small tasks can be on big CPU and also big task can be on

little CPU (probably idle little CPU).

Over-utilized big CPUs' SD will have same issue for the tasks happened to

be on a big CPU previously but better to be on a little CPU later.

What do you think? It can be tricky but it could be better to mark as

over-utilized when all the CPUs in the SD are actually over-utilized for

both task placement and lb."
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Hmm, that's some new info. So you want to say that we have some things for "overutilization and sub optimal task placement" ? I haven't read about the new implementations yet
[OnePlus 3 & 3T Cross Device Development] vinax89:
Morten Rasmussen from ARM stated that ideally, the criteria for calling for help (setting the overutilized flag at the root_domain) should be:

It is not possible to balance the tasks within the cluster such that every cpu has a minimum of spare cycles.

Figuring out the whether it is possible to balance the tasks such that none of them are constrained in term of available cpu cycles isn't easy. Until now we have taken a much more conservative approach by making the criteria: If any cpu is over-utilized. As this is very easy to determine and should cover all the cases covered by the ideal criteria above, although we will call for help in many cases where it isn't necessary.

Semantics for overutilized would be:

Inner "overutilized": This kind "overutilized" is the schedule domain internal issue and can be adjusted within schedule domain; so scheduler should find best combination between tasks and CPUs in the schedule domain.

Outer "overutilized": This kind "overutilized" is that schedule domain cannot adjust by itself so ask other scheduler domains to help pull tasks. Usually we expects this is a higher capacity scheduler domain to pull tasks so can improve performance.

Global "overutilized": This kind "overutilized" is that schedule domains should spread tasks as possible and this may happen for task migration from higher capacity schedule domain to lower capacity schedule domain.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Wow! A lot of things going on here!

Your informative posts are very highly appreciated! :good: :good: :good:
[OnePlus 3 & 3T Cross Device Development] vinax89:
Thank you, I am learning much from your input too [MENTION=5060769]Mostafa Wael[/MENTION]. But I need to rest as I have taken a few sleeping pills to combat severe insomnia and my work doesn't recognize weekends or holidays. LOL
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
I need to rest my eyeballs as well as finish writing an article i started earlier.

Will keep fine tuning EAS for now
[OnePlus 3 & 3T Cross Device Development] niwia:
For those of you don't know. Boeffla has 4.0.2 stock kernal in his website. If you hate backing up and restoring like me flash it insted. I don't know if I told something stupid. I think it's better than backing up. :)
[OnePlus 3 & 3T Cross Device Development] Matokov:
Omg boys, crazy battery life :D Freedom 2.3 + Render + Burnout PR3. First battery cycle.

Speed and battery life are perfect but performance (smooth) in comapre with bluspark is worse.... I believe that next update will be better ;)
[OnePlus 3 & 3T Cross Device Development] Mar-cel:
What is EAS? :confused:
[OnePlus 3 & 3T Cross Device Development] isoladisegnata:
On experience wifi dont work
[OnePlus 3 & 3T Cross Device Development] manjartens:
Flash Stock first, then render again . Worked for me.
[OnePlus 3 & 3T Cross Device Development] isoladisegnata:
Have u link?
[OnePlus 3 & 3T Cross Device Development] manjartens:
No, but in downloads from lord boeffla you can find oos Stock Kernel.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
use the search button. Really it is not hard. I am sorry but i wrote it zillion of times....
[OnePlus 3 & 3T Cross Device Development] comediiian:
EA Sports? :D
[OnePlus 3 & 3T Cross Device Development] Mar-cel:
Energy aware scheduling?
[OnePlus 3 & 3T Cross Device Development] liam_davenport:
From the second charge, Hoping it settles after the next charge
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Testing some changes to some tunables, looks promising so far in terms of performance. Will see how battery life goes.
[OnePlus 3 & 3T Cross Device Development] RenderBroken:
There really isn't going to be a Goldilocks value for Stock OOS as far as I am concerned. We are missing things that EAS really needs to work properly. The main one being proper task placement and cpu utilization for UI threads. I am currently working on an LOS-EAS rom build and will see what I can pull in from it to make EAS on OOS work better but OOS is missing quiet abit of important rom side changes. One way or the other guys, we will have a fully working EAS implementation on the OP3.
[OnePlus 3 & 3T Cross Device Development] fcisco13:
So far it's running good on FreedomOS, thanks for your hard work.
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Well I disagree a bit with the fact that OOS will be stalled. But you are 100% right about the fact that we are missing some commits for the UI. Just hang on a bit. I think some changes can rectify the performance consistency issue we are facing. :good:
[OnePlus 3 & 3T Cross Device Development] vinax89:
Yep, agree with you on that. But LOS-EAS would be nice! :good:
[OnePlus 3 & 3T Cross Device Development] :
Here is what happened with 48+ hours usage with the values [MENTION=5207359]vinax89[/MENTION] provided

1)performance improved like 5-10%(ie phone was more smother not that it was lagging before but it became more smooth

2)battery life improved a bit also

Overall this values improved the performance

Here’s screnies

Edit:before going to sleep I activate flight mode
[OnePlus 3 & 3T Cross Device Development] vinax89:
Not my values, it's [MENTION=5438598]RenderBroken[/MENTION] that provided these values. Give thanks to him! :good:
[OnePlus 3 & 3T Cross Device Development] :
Well then in that case thanks to [MENTION=5438598]RenderBroken[/MENTION] for his awesome kernel and values that outdid what non eas can do. Yes there’s still stuff to do but I know it will be completed by this awesome dev:highfive:
[OnePlus 3 & 3T Cross Device Development] RazorBlade123:
Which values?
[OnePlus 3 & 3T Cross Device Development] :
/dev/stune/background/schedtune.boost 0

/dev/stune/foreground/schedtune.boost 5

/dev/stune/top-app/schedtune.boost 15

/dev/stune/schedtune.boost 10

Thanks to [MENTION=5438598]RenderBroken[/MENTION] for this
[OnePlus 3 & 3T Cross Device Development] RazorBlade123:
How much sot did you get before EAS?
[OnePlus 3 & 3T Cross Device Development] :
Before values 4h 33m sot at 36%

Now 4h 30m sot at 48%

Usage is pretty much same

I don’t use social media so phone goes to deep sleep faster

And also I don’t game

Edit:before eas 4 to 5h max with 2% battery left
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
5.75 hrs SOT here, 24 hours total time, 15% left, Benchmark runs included and some brutal multi tasking. That's what i call efficiency :good:
[OnePlus 3 & 3T Cross Device Development] abhibnl:
Share those values ?
[OnePlus 3 & 3T Cross Device Development] mittimus:
How to apply them?
[OnePlus 3 & 3T Cross Device Development] :
+1

---------- Post added at 01:52 PM ---------- Previous post was at 01:51 PM ----------

Just navigate to the path given and change values to the one given here using a text editor
[OnePlus 3 & 3T Cross Device Development] RazorBlade123:
Edit:

How's the performance when compared to stock kernel?
[OnePlus 3 & 3T Cross Device Development] :
Deleted

Edit sorry I didn’t tried the non eas kernel
[OnePlus 3 & 3T Cross Device Development] mittimus:
I have tried to modify them manually but after reboot they become all "0".

Tried also to create an init.d script in KA but not success. Any solutions?
[OnePlus 3 & 3T Cross Device Development] :
Yep they reset after every reboot
[OnePlus 3 & 3T Cross Device Development] habylab:
He/she understands that, as they've tried to create a script.
[OnePlus 3 & 3T Cross Device Development] Konskl:
Use tools>user settings to retain the settings after every reboot ;)
[OnePlus 3 & 3T Cross Device Development] Mostafa Wael:
Alright fellows, buckle up for some testing.

/dev/stune/top-app

schedtune.boost

= 8

schedtune.prefer_idle

= 0

/dev/stune/foreground

schedtune.boost

= 2

schedtune.prefer_idle

= 1

/dev/stune/background

schedtune.boost

= 0

schedtune.prefer_idle

= 1

To change those values:

1- with the aid of a root explorer, navigate to the paths written in bold

2- open the files written in italics

3- edit the value inside to the corresponding numbers after the '='

Now onto something new, governor settings!

Little Cluster

up_rate_limit_us

= 1000 (unchanged)

down_rate_limit_us

= 6000

Big cluster

up_rate_limit_us

= 2000

down_rate_limit_us

= 6000

To apply those values:

1- use any kernel tuning app like Kernel Aduitor app

2- navigate to CPU tab and then open the governor settings for each cluster

3- change the values to the correspond written ones

BUG:

The governor settings for the big cluster resets to the default 1000 values once the screen goes off. Good news is that even with the little cluster's changes only, you still get noticeable improvement in speed imo :rolleyes:

Perhaps [MENTION=5438598]RenderBroken[/MENTION] can have a solution for that inconvenience of big cluster governor settings being reset after screen goes off.

Hope I helped you, and sorry for the delay.

P.S. I get 10-13%/hr active drain rate with that setup, and performance is no slouch at all!

Will test negative values later on. Right now I am resembling a similar setup to the Pixel's cgroups settings (top-app, foreground and background folders i mean)

Cheers!

-TDK
[OnePlus 3 & 3T Cross Device Development] xkhen0017:
[MENTION=5060769]Mostafa Wael[/MENTION]

Not in my case. @.@ Big cluster doesnt reset whenever my screen goes off. Im using exkernel manager btw.

I'll try your settings and will feedback after few days of using it. :good:
[OnePlus 3 & 3T Cross Device Development] abhibnl:
I believe [MENTION=5438598]RenderBroken[/MENTION] must already be aware but wanted to notify in case. Andi just pushed an update to his kernel because of some changes by OnePlus related to regulator voltage and he mentioned the values were set too high as a minimum value. Just wanted to update here (Y)
[OnePlus 3 & 3T Cross Device Development] RenderBroken:
Feel free to post useful information anytime. I had seen something related to voltage pushed to OP's official source. I will see if its the same thing. I am just finishing up me LOS-EAS kernel build and I am really happy with it. Where I was having micro lag when scrolling lists on OOS-EAS. I have none with my LOS EAS build. I will most likely be moving to LOS for awhile.
[OnePlus 3 & 3T Cross Device Development] DarKAngel1234:
Honestly in love with your Kernel on: https://xdaforums.com/oneplus-3/development/rom-zenity-resurrection-remix-n-t3551384

It is the fastest and smoothest I have used to date. Of coarse the EAS changes need to be implemented on the ROM side in order for things to work really well. I guess no way around that, if you are planning on releasing your kernel as stand alone. Pretty damm impressed so far.

Thanks
[OnePlus 3 & 3T Cross Device Development] fcisco13:
Was using it on freedom and i did notice a bit of lag scrolling.
[OnePlus 3 & 3T Cross Device Development] RenderBroken:
My newest build should work on that rom you linked. Currently, its just the latest LOS with EAS changes. Nothing else right now. Once EAS is solid, I will bring in the fun. I already have a roadmap for everything I have planned for R1.
[OnePlus 3 & 3T Cross Device Development] Duncan1982:
I concur with your Kernel on RR its one Smooth Criminal, I'm also using DU and that ROM is on point, but thses are my areas and focus on fluidity and decent battery life , not looking for 27hrs SOT just want balance without comprises, this and you deliver, So your EAS should flash fine on RR? Hmmm let me beta test lol