[Kernel | Android 10 | One UI 2.5 | FUF5/FUH1/FUJ2/FUK1/FVC2/FVH1] BeastMode Kernel v2 for N960F | v2.18f1a3 | 20230223

[Tops1]

ok thanks, and it has been fixed

Thanks Guesstures fixed

 

[ykkfive]

Now I migrated bm v2.02m + Alexis 2.8 combination. All seems decent for now. Still boeffla and double tap sections are missing. But it's okay.
Here is the devchecks ram performance attachment. (on v2.02)

I am going to perform antutu and geekbench and post here.

u mean 2.04m?

I am on v2.05

Ram performance is decreased, confirmed with doing devcheck comparison and antutu bench.

tap to wake and sleep options are gone.
boeffla options are gone.

Accordig to Devcheck,

Cmemcopy: around 5000 Mb/s
Cmemset: aroud 7500 Mb/s

on R154 these were 10000 MB/s and 15000 Mb/s respectively.

Cpu an GPU performance are good.

I am on Alexis 2.9 Note 9 SM N960F


And also the voltage table that given by dev is passed two full antutu bench. No crashes.

i have did some tests today and yes, 2.02 is the fastest one, it was the original one without any "enhancements" in other aspects like cpu/gpu overclocking. it is not unusual that these enchancements can be beaten by the one without in terms of performance. it all depends on the usage, and more importantly everthing comes with a price. so you may find it at stock max speed outperforms an overclocked cpu due to the heat generated (which trigger the mechanism to lower the cpu freq as to cool it down). eg a 10 seconds task running with 2000Mhz may be better than 3 seconds with 2400mHz plus 7 seconds with 1700Mhz. you see what i mean? of coz, once again, it depends on the usage and the way of using it like benchmarking or daily use

anyway, thanks for your feedbacks, as well as others. without you guys' feedback i couldnt discover the bugs myself

also, i may consider to make an extreme version, which will be rebased on 2.02 with FUF5 but without any unneccessary changes for those who focus more on the speed due to different usage patterns if there are demands for it. but in general, 2.02 is still working fine with FUF5 except samsung account login issues for some users i believe

on the other hand, i will continue to cherry pick some useful changes to optimize it in general for the main stream version

thanks

 

[ykkfive]

Thanks Guesstures fixed

great
but it is not a good news for me coz i like the idea with double taps to show me the time with always on display and it is incompatible with the dt2w since dt2w will bypass the aod and goes striaght to the desktop. seems like i have to reintroduce triple taps to wake again

 

[otaking71]

u mean 2.04m?


i have did some tests today and yes, 2.02 is the fastest one, it was the original one without any "enhancements" in other aspects like cpu/gpu overclocking. it is not unusual that these enchancements can be beaten by the one without in terms of performance. it all depends on the usage, and more importantly everthing comes with a price. so you may find it at stock max speed outperforms an overclocked cpu due to the heat generated (which trigger the mechanism to lower the cpu freq as to cool it down). eg a 10 seconds task running with 2000Mhz may be better than 3 seconds with 2400mHz plus 7 seconds with 1700Mhz. you see what i mean? of coz, once again, it depends on the usage and the way of using it like benchmarking or daily use

anyway, thanks for your feedbacks, as well as others. without you guys' feedback i couldnt discover the bugs myself

also, i may consider to make an extreme version, which will be rebased on 2.02 with FUF5 but without any unneccessary changes for those who focus more on the speed due to different usage patterns if there are demands for it. but in general, 2.02 is still working fine with FUF5 except samsung account login issues for some users i believe

on the other hand, i will continue to cherry pick some useful changes to optimize it in general for the main stream version

thanks

It seems the voltage bug exists on the other kernels that support it. I wonder if it's a bug in the kernel managers since they're modified ports. It's really a shame the dev community thinned out so bad. That being said...yea..there's definitely a lot of potential, but man..this is gonna be some work to get most of it out of the way.


I'd actually venture to guess if you capped the cpu's frequency at either the triple core or dual core max speed...and tuned the voltages correctly...you'd see a significant performance and battery gain. Especially if you tuned the mif/memory speeds to scale sanely instead of this brute force methodology samsung did. I'd say conservatively you'd see something around a 10% performance boost and 20% battery.

 

[ykkfive]

It seems the voltage bug exists on the other kernels that support it. I wonder if it's a bug in the kernel managers since they're modified ports. It's really a shame the dev community thinned out so bad. That being said...yea..there's definitely a lot of potential, but man..this is gonna be some work to get most of it out of the way.


I'd actually venture to guess if you capped the cpu's frequency at either the triple core or dual core max speed...and tuned the voltages correctly...you'd see a significant performance and battery gain. Especially if you tuned the mif/memory speeds to scale sanely instead of this brute force methodology samsung did. I'd say conservatively you'd see something around a 10% performance boost and 20% battery.

which voltage bug are you talking about?

yeah, during the development, there were some gains in performance, by 5% followed by another 5%, and a bit in battery consumptions. and as i said there are still rooms to under volt the cpu, especially the lower freqs, those shown b4 are just conservative wild guess from my experience for reference only

 

[otaking71]

which voltage bug are you talking about?

yeah, during the development, there were some gains in performance, by 5% followed by another 5%, and a bit in battery consumptions. and as i said there are still rooms to under volt the cpu, especially the lower freqs, those shown b4 are just conservative wild guess from my experience for reference only

the bug i mentioned before where you change the frequency sliders go poof....it exists in two other kernels...so i'm thinking it's the app.


that being said...i'm not sure it's working properly as my phone can completely do the lowest global voltage slider no problem...i'd be surprised if i got that lucky of a chip (it benched at top 99% for exynos note 9s on 3dmark)

i'm wondering....are you able to alter the memory voltage alongside it's frequency? it would be interesting to do two variants based on the properties that would be desirable...the most performance (fastest gpu/higher frequencies) or the most battery (enable the top frequencies that make sense and the most power efficient levels that work together properly)...two variants that could best be optimized once we fully understand the _ACTUAL_ safe voltage curves of these things. an overclock of the memory controller could be rather interesting if that's possible.

I'm kinda willing to buy a second phone to actually take it apart and probe voltages to really verify it works...not sure if there's a schematic for that out there.

 

[ykkfive]

the bug i mentioned before where you change the frequency sliders go poof....it exists in two other kernels...so i'm thinking it's the app.


that being said...i'm not sure it's working properly as my phone can completely do the lowest global voltage slider no problem...i'd be surprised if i got that lucky of a chip (it benched at top 99% for exynos note 9s on 3dmark)

i'm wondering....are you able to alter the memory voltage alongside it's frequency? it would be interesting to do two variants based on the properties that would be desirable...the most performance (fastest gpu/higher frequencies) or the most battery (enable the top frequencies that make sense and the most power efficient levels that work together properly)...two variants that could best be optimized once we fully understand the _ACTUAL_ safe voltage curves of these things. an overclock of the memory controller could be rather interesting if that's possible.

I'm kinda willing to buy a second phone to actually take it apart and probe voltages to really verify it works...not sure if there's a schematic for that out there.

oic... from my observstion (applying the settings after boot manually), the new voltage settings are stored as i mentioned earlier

you can check it by issuing the command below:
cat /sys/devices/platform/17500000.mali/volt_table

also you can check your phone's asv by going to the kernel manager and select the device page. under the asv header, those rows show your phone's overclock ability/power efficiency. the higher the value means the stronger the capability (max 15 if i remember correctly, above 7 or 8 should be fine)
or you can issue the command below
cat /sys/kernel/debug/asv_summary

 

[otaking71]

oic... from my observstion (applying the settings after boot manually), the new voltage settings are stored as i mentioned earlier

you can check it by issuing the command below:
cat /sys/devices/platform/17500000.mali/volt_table

also you can check your phone's asv by going to the kernel manager and select the device page. under the asv header, those rows show your phone's overclock ability/power efficiency. the higher the value means the stronger the capability (max 15 if i remember correctly, above 7 or 8 should be fine)
or you can issue the command below
cat /sys/kernel/debug/asv_summary

so it looks like the voltages DO work even with speed changes. I'm surprised mine will max out the undervolt slider.

According to my asv table

mif:7
int:7
cl0:10
cl1:8
g3d:6


But yea..i'm familiar with binning..I did all my previous undervolts based on the pvs bin table for snapdragon 805s....is there a similar command to see the cpu voltages a la the gpu voltages you posted above? I'm still surprised a 6 was able to go THAT low at max speed.

what command can i use to manually set the voltages...and any idea of what the granularity is of value it'll take? (the sliders work on 6.25mv.) i can at least work on a curve that way.

and from what I see....there's one more possible important voltage...not sure what the int setting is.....i wish there was more consistency in how they labeled these things....like the gpu's table in the kernel source references mem and not mif....but int is both in the kernel source gpu table..and the avs table...would definitely help to understand what in the world that is. the internal bus speeds and voltages... if it behaves anything like a desktop cpu...you can actually get _MORE_ stability if this is undervolted into the correct range based on your cpu core voltages.

 

[ykkfive]

so it looks like the voltages DO work even with speed changes. I'm surprised mine will max out the undervolt slider.

According to my asv table

mif:7
int:7
cl0:10
cl1:8
g3d:6


But yea..i'm familiar with binning..I did all my previous undervolts based on the pvs bin table for snapdragon 805s....is there a similar command to see the cpu voltages a la the gpu voltages you posted above? I'm still surprised a 6 was able to go THAT low at max speed.

what command can i use to manually set the voltages...and any idea of what the granularity is of value it'll take? (the sliders work on 6.25mv.) i can at least work on a curve that way.

and from what I see....there's one more possible important voltage...not sure what the int setting is.....i wish there was more consistency in how they labeled these things....like the gpu's table in the kernel source references mem and not mif....but int is both in the kernel source gpu table..and the avs table...would definitely help to understand what in the world that is. the internal bus speeds and voltages... if it behaves anything like a desktop cpu...you can actually get _MORE_ stability if this is undervolted into the correct range based on your cpu core voltages.

unfortunately, i couldnt find the voltage table, or there's none actually. and i have read the kernel managers, their cpu voltage table are referring to an old, non-existing file named something like exynos-pm, which i think it's depreciated. so even i make it chargeable you will have to manually edit the volt or by scripts. anyway, i wonder why there's no cpu voltage control in kernels nowadays (there were lots of kernel with different controls b4, mit, int, volt, everything)

more, i have adjusted the gpu voltages table and it seems fine for me. i don wanna squeeze them too much coz its my dd

 

[otaking71]

unfortunately, i couldnt find the voltage table, or there's none actually. and i have read the kernel managers, their cpu voltage table are referring to an old, non-existing file named something like exynos-pm, which i think it's depreciated. so even i make it chargeable you will have to manually edit the volt or by scripts. anyway, i wonder why there's no cpu voltage control in kernels nowadays (there were lots of kernel with different controls b4, mit, int, volt, everything)

more, i have adjusted the gpu voltages table and it seems fine for me. i don wanna squeeze them too much coz its my dd

give me the commands for the gpu voltage ...i'm still on the note 4 for now...i'll come up with a table brute forced to mine..and we can start some testing there.


i think they're gone because fewer devs and fewer people that know wtf they're talking about are around to test and debug these things since they locked down us market bootloaders. like https://xdaforums.com/t/kernel-eol-...nel-for-samsung-galaxy-note-9-exynos.4081197/ says undervolting is useless and 100 mv is impossible..

last time i was active on xda....they said my phone was not rootable if you took the newer software upgrade......i ended up being the one figuring out how to do it after I broke my phone and got a replacement that had the newer software. I'm not much of a coder/programmer...but I've done enough to understand what's going on.

as far as i can tell...there's 4 main voltages we can adjust. if there's _ANY_ standardized table that you see/run into in the kernel sources...it'll help flesh out a table we can use for most people. (ie we see each bin is one or a two step difference on the voltage curve).


I'll start by forcing my n960f to actually get it's gpu to crash under load and then work upto what it actually needs..so give me a few days and i'll have it worked out. If i can't crash it,, we know the undervolts aren't really working properly

 

[ykkfive]

give me the commands for the gpu voltage ...i'm still on the note 4 for now...i'll come up with a table brute forced to mine..and we can start some testing there.


i think they're gone because fewer devs and fewer people that know wtf they're talking about are around to test and debug these things since they locked down us market bootloaders. like https://xdaforums.com/t/kernel-eol-...nel-for-samsung-galaxy-note-9-exynos.4081197/ says undervolting is useless and 100 mv is impossible..

last time i was active on xda....they said my phone was not rootable if you took the newer software upgrade......i ended up being the one figuring out how to do it after I broke my phone and got a replacement that had the newer software. I'm not much of a coder/programmer...but I've done enough to understand what's going on.

as far as i can tell...there's 4 main voltages we can adjust. if there's _ANY_ standardized table that you see/run into in the kernel sources...it'll help flesh out a table we can use for most people. (ie we see each bin is one or a two step difference on the voltage curve).


I'll start by forcing my n960f to actually get it's gpu to crash under load and then work upto what it actually needs..so give me a few days and i'll have it worked out. If i can't crash it,, we know the undervolts aren't really working properly

yeah sure, i still have the script on my note4

actually things get more and more complicated, i found where i can get the volt in the sources, but what's next? the values will be manipulated somewhere, especially i am no expert in electronics, so when i see something like pin1 pin2 etc i will go away and avoid touching them since i have no clues what they are, what msg they carry etc

 

[otaking71]

yeah sure, i still have the script on my note4

actually things get more and more complicated, i found where i can get the volt in the sources, but what's next? the values will be manipulated somewhere, especially i am no expert in electronics, so when i see something like pin1 pin2 etc i will go away and avoid touching them since i have no clues what they are, what msg they carry etc

if you figure out how to read any of the voltages...I think I can figure out how the pin setting works. It should be simple math to figure out how it's actually controlled. And I'd guinea pig on myself once we're able to try it.

 

[otaking71]

i think i found where to read it!

/sys/kernel/debug/opp/cpu4 and /sys/kernel/debug/opp/cpu0. There's a bunch of of u_volt entries there. I'm assuming it just assign to the first core of each cluster and the others follow

 

[otaking71]

and holy hell this is a screwy factory curve...lol...the top speed has a significantly lower voltage than the next step down.

 

[otaking71]

after looking over the curve a bit...the real intended frequencies or actual ideal frequencies are 1053 for the small cores and 1690/1794 for the large cores.

 

[ykkfive]

after looking over the curve a bit...the real intended frequencies or actual ideal frequencies are 1053 for the small cores and 1690/1794 for the large cores.

holly, you can make a curl with optimal settings quickly. that's based on the default voltages?

also, are you able to plot a curve or draw a table showing the capability or effieiency base on the freq? coz i once found a dev did so although i could only understand some parts of it

 

[otaking71]

holly, you can make a curl with optimal settings quickly. that's based on the default voltages?

also, are you able to plot a curve or draw a table showing the capability or effieiency base on the freq? coz i once found a dev did so although i could only understand some parts of it

that's looking at the stock table literally as is. samsung literally breaks their curve at a certain point just to say it performs at a certain level. assuming we actually get the voltages we are looking for actually working....i figure 1 - 2 weeks tops for each voltage setting optimized that we get working.

 

[otaking71]

But looking at it some more.....the ideal frequency curve (assuming a properly working governor that literally only fires up the big cores when we need them))....would end up looking like small cores at 455-1053 and the big cores at 1066/1170-1794. This curve would allow a seamless transition to when you need performance at it's highest efficiency. Otherwise I'd go 741-1794 on the big cores.

 

[ykkfive]

But looking at it some more.....the ideal frequency curve (assuming a properly working governor that literally only fires up the big cores when we need them))....would end up looking like small cores at 455-1053 and the big cores at 1066/1170-1794. This curve would allow a seamless transition to when you need performance at it's highest efficiency. Otherwise I'd go 741-1794 on the big cores.

well this is a dilemma
"personally", i like to restrict the small cores to below half way like 8xx to 9xx, as to force the tasks to be executed on the big cores. so when a task could not be finished with the small cores it will be processed by the big cores since they are more efficient. and that's why i tried to push them to the big cores in queue all the times if possible. however when i run the benchmarks it is another story.

of coz i understand that daily usages is a different thing than the benchmarks. so i stick to my plan with what you called smooth transition, where big cores cover a part of the max freq in the small cores. so it seems my methodology is correct, rite?

 

[otaking71]

well this is a dilemma
"personally", i like to restrict the small cores to below half way like 8xx to 9xx, as to force the tasks to be executed on the big cores. so when a task could not be finished with the small cores it will be processed by the big cores since they are more efficient. and that's why i tried to push them to the big cores in queue all the times if possible. however when i run the benchmarks it is another story.

of coz i understand that daily usages is a different thing than the benchmarks. so i stick to my plan with what you called smooth transition, where big cores cover a part of the max freq in the small cores. so it seems my methodology is correct, rite?

absolutely correct....there's a further benefit to that curve which is the mif. the above frequency curve literally gives you every option for scaling at pretty much the ideal power cost. I really do think the mif is an underexplored aspect of this cpu.