yashsingh1/xdaforums huggingface dataset:
[Galaxy S III Original Android Development] rlorange:
There are some sys control settings to fiddle with.

These are from best multitasking swap script

echo "524288" > /proc/sys/fs/file-max

echo "32000" > /proc/sys/fs/inotify/max_queued_events

echo "256" > /proc/sys/fs/inotify/max_user_instances

echo "10240" > /proc/sys/fs/inotify/max_user_watches

echo "10" > /proc/sys/fs/lease-break-time

echo "1048576" > /proc/sys/fs/nr_open

echo "0" > /proc/sys/kernel/panic

echo "0" > /proc/sys/kernel/panic_on_oops

echo "64" > /proc/sys/kernel/random/read_wakeup_threshold

echo "128" > /proc/sys/kernel/random/write_wakeup_threshold

echo "0" > /proc/sys/kernel/sched_child_runs_first

echo "600000" > /proc/sys/kernel/sched_latency_ns

echo "1" > /proc/sys/kernel/sched_min_granularity_ns

echo "400000" > /proc/sys/kernel/sched_wakeup_granularity_ns

echo "5" > /proc/sys/vm/dirty_background_ratio

echo "1000" > /proc/sys/vm/dirty_expire_centisecs

echo "90" > /proc/sys/vm/dirty_ratio

echo "2000" > /proc/sys/vm/dirty_writeback_centisecs

echo "2" > /proc/sys/vm/drop_caches

echo "8192" > /proc/sys/vm/min_free_kbytes

echo "2" > /proc/sys/vm/min_free_order_shift

echo "1" > /proc/sys/vm/oom_kill_allocating_task

echo "3" > /proc/sys/vm/page-cluster

echo "0" > /proc/sys/vm/panic_on_oom

echo "100" > /proc/sys/vm/swappiness

echo "20" > /proc/sys/vm/vfs_cache_pressure
[Galaxy S III Original Android Development] nfsmw_gr:
Andreilux,any comment on these settings?

Some dev's claim these could make a difference,some others can't configure them properly...what's your opinion about these in specific?
[Galaxy S III Original Android Development] AndreiLux:
Yes, this is the kind of feedback I've expected on ABB. First of all, I'll leave the advanced users understand it how it works and how you can manipulate your threshold voltage.

I still need to release the kernel for the Note 2 and get feedback from them.

If everything works well, then I'll be raising the frequency roof by quite a bit.

Some of them I know what they do, some I need to educate myself on. Can't really say much.

One thing for sure, disabling kernel panics and oops' is an IDIOTIC thing to do, afaik that part originated from zepphinox and whatever that ****ty monster script was called.
[Galaxy S III Original Android Development] ahac85:
Hi I would like to know if the sd cache size issue has been fixed in v36, theres no mention in changelog

Sent from my GT-I9300
[Galaxy S III Original Android Development] MuertoKo:
Doesn't look like, I have STweaks on full default and after doing this:

cat /sys/block/mmcblk0/bdi/read_ahead_kb

and

cat /sys/block/mmcblk1/bdi/read_ahead_kb

I still get 128Kb as only value in there, while it should be 256 - 1024 (or whatever is set by default)
[Galaxy S III Original Android Development] ffolkes:
As always, thanks for all your awesome work! I have been using this on my Note 2 for a while, and so far it seems to be working normally.

I wanted to ask if you could expound on what the adjustments themselves are supposed to do. I understand (or at least I think I do) the electrical aspect of it and the bias, but I'm not sure how that ties into the "750mv" default I see in STweaks for each slice. I'm sure I won't be the last person to ask...in simple terms, in what scenario would someone need to adjust that? Isn't the A in ABB for adaptive? I want to have a better understanding before I mess with anything.

Also, thanks for the brightness control in mDNIe. That's an excellent idea, and it has been working very well for me tonight.
[Galaxy S III Original Android Development] Vinzie:
What values did you use for ABB ??? Just to use as reference ofcourse :)
[Galaxy S III Original Android Development] mattiadj:
I'm the dev of this script! Yes I know (but only from recent...) that disabling panic is dangerous... Now I'm trying only with some lmk tweaks and with 36 kernel I can say it's a brilliant situation with very good multitasking

From universe with my gs3
[Galaxy S III Original Android Development] AndreiLux:
I forgot to fix that/look into it, sorry. I did a minor mistake in the uci.sh actionscripts.

Version 36.1:

- Fixed sd card cache size controls. (ramfs repack only)

Unless you have an ASV0 or ASV1 chip you shouldn't have 750mV as default on all slices, that's a problem. Please report back on your ASV number as described in the OP.

Again, it's explained in the OP: the body bias is the gate voltage minus the body voltage. Look at the table I've posted, that's the default values for the 4412 Prime in terms of body bias. If you raise the body bias (Either through raising the gate voltage, or through lowering the body voltage), you can achieve better overclocking. People would want to do this on the last slice primarily.

The reverse applies on the lower frequencies.

I've seen the disabling of kernel panics around much earlier before you starting doing scripts, you're not the source.
[Galaxy S III Original Android Development] JustArchi:
What's the freaking point of disabling kernel panics anyway? If kernel encounters critical error and isn't able to continue it's work then there is a reason for that, do you think that anyone would implement such feature to annoy users? No, that's called warning and debug logs. Also known as kern.log.
[Galaxy S III Original Android Development] ffolkes:
Mine is ASV1, which from what I can gather isn't a good thing.
[Galaxy S III Original Android Development] AndreiLux:
Ah, good. I was afraid I did something wrong in the code. Yes, you have an exceptionally crappy chip. In fact you're the first user I ever see with ASV1.

I'm going to release the Note 2 kernel during the day. I suggest not implementing ABB for your own release until things are confirmed to be working correctly for everybody.
[Galaxy S III Original Android Development] Tuckycv:
I'm using ultimarom V12, and been on perseus for a while, I was using status bar transparency on the ultimarom, after the update yesterday I no longer can get the status bar to transparent. Is something about the kernel that broke it?
[Galaxy S III Original Android Development] Erahgon:
Ouch...

Sent from the present, which is now in the past.

---------- Post added at 07:43 PM ---------- Previous post was at 07:42 PM ----------

Highly doubtful.

Sent from the present, which is now in the past.
[Galaxy S III Original Android Development] rlorange:
Andreilux

Just wondering if you could shed some light on something.

I had an idea to port libs from an n8000 ROM and then use newer mali kernel drivers from n8000 sources. My assumption was that CM 10.1 used these drivers as mentioned on github.

With some help we compiled n8000 Mali drivers from sammy source with Siyah so I could use dual boot to transplant libs an from n8000 rom to test.

To our surprise the drivers worked without n8000 rom libs if fact they didn't seems to be any different!!

So what's going on here? Do you know which sources CM10.1 libs come from? Is the above scenario even possible if the n8000 drivers really were newer?
[Galaxy S III Original Android Development] STAticKY:
Random thought refarding all this AVS stuff...

Im thinking that we could have 4412s out there that are binned at low AVS levels but in reality they could well be marinally off very high AVS levels bar a couple problems on a few steps ect make it have to be binned at say avs2 but really we can get them performing to their full potential by finding the weak spots and restrict them to what they can handle and unleash the rest???

Truth???
[Galaxy S III Original Android Development] MuertoKo:
Thanks :D Working now! :D :D
[Galaxy S III Original Android Development] ffolkes:
Heh, I'm flattered. :P Although it handles well at higher clocks oddly. I have always been able to run 1800 at 1225mv with no problems, yet at 200 even 900mv isn't enough. I hope my Note 3 fares better.

And I agree, I wasn't planning on it until you made the official thread updates. Thanks again for all your work!
[Galaxy S III Original Android Development] chiupc94:
What's the difference between 36.1 and 36??
[Galaxy S III Original Android Development] JustArchi:
Bugfix with readahead.
[Galaxy S III Original Android Development] chiupc94:
Thanks. Is it essential to flash 36.1?? Because I just flashed 36
[Galaxy S III Original Android Development] Erahgon:
Just trying to understand: how do I use the ASV table in the OP to underclock my CPU ideally. What did the faded green/blue colour represent? I'm on ASV 3, as reported by the abb_info sysfs.

Are the current default ABB values in STweaks ideally calculated to my chip, or can I optimize them further?

Sent from the present, which is now in the past.
[Galaxy S III Original Android Development] AndreiLux:
I think you're confused. CM uses the Mali libs from the leaked 4.2.1 ROM together with R3P1.

I'm going to jump to the assumption that we're talking about very different drivers here since the N8000 for sure doesn't have 4.2.1 stock ROM or kernel sources.

More or less. Chips come with a manufacturer's safety margin. I've already mentioned that things like temperature can alter a transistor's threshold voltage, so they put the default values as such so that it will work both at -20°C and also at 70°C. What we're doing with undervolting is to eliminate/shrink that safety gap.

If you have body bias control and normal voltage control, you essentially have ASV binning control since those two things are the only thing which differentiate different ASV groups.

It's because the bias jump from ASV1 to ASV2 is big, look at the table I've posted. It's probably too big for practical purposes, you could get away with raising the body voltage and improving power consumption like that.

I've explained all these things in the OP. Please re-read it several times if you don't understand it.

And if you still don't understand it, leave the fingers off of it.
[Galaxy S III Original Android Development] cba1986:
After the last update i cannot OC to 1704 anymore. In alpha 35 i could OC + UV -100mv on that freq. Now i'm stuck on a bootloop. Anyone have any ideas?

Thanks.

EDIT: I didn't touch abb values..
[Galaxy S III Original Android Development] rlorange:
Andrei thanks for clearing this up re Mali drivers...

So to work we would need libs from a Samsung 4.1.2 ROM cooked up to run on a kernel compiled with the same r3p1 drivers...

Somehow we thought this was the case for the n8000... drag
[Galaxy S III Original Android Development] AndreiLux:
You need to state your ASV group if you feel there was a change in behaviour.

I already tried that. The issue is somewhere else.
[Galaxy S III Original Android Development] habylab:
Andrei, are the settings for the ABB based on that Google spreadsheet you asked people to fill in months ago?

Sent from my Galaxy S3. Long live the original Galaxy S :)
[Galaxy S III Original Android Development] cba1986:
I will state it when i can exit the bootloop cycle.

PD: anyone knows how to reset Stweaks without making a factory reset?

Thanks
[Galaxy S III Original Android Development] AndreiLux:
Which settings? The default settings right now should the stock Samsung mapping, unless I did some mistake. The spreadsheet was for partial information.

Delete /data/.perseus or ADB in recovery and do "echo CONTROLSWITCH_CPU=off > /data/.perseus/override.profile".
[Galaxy S III Original Android Development] Anakha56:
So it appears I have a ASV of 3, I feel like saying that sucks but I have no idea if that is true or not.
[Galaxy S III Original Android Development] rlorange:
Get aroma file manager for next time then you can just directly delete the profile from recovery...

I have ASV 4. Had Good results on undervolting another 50mv on all but 1800mhz step... boot loop too lol!
[Galaxy S III Original Android Development] Kaydin:
Is it me, or the notification LED doesn't work correctly since version 36? On version 35, it seemed like it was working great. Now it seems that it doesn't show the right colors on notifications (instead of yellow, it shows almost green), and it blinks faster (seems like it doesn't even turn off completely - it just fades and turns back on). Anyone else experiencing this? Tried deleting my settings and flashing 36.1. Same behavior.
[Galaxy S III Original Android Development] habylab:
I have ASV2. That's pretty bad, right?
[Galaxy S III Original Android Development] rlorange:
So my default slice 4 body voltage is 1300.

If I raise this to 1400 does that mean I SHOULD be able to lower the gate voltage for 1.7/1.8 GHz steps?
[Galaxy S III Original Android Development] RohanAJoshi:
me too..

but dont know its good or bad..
[Galaxy S III Original Android Development] habylab:
Assuming gate voltage is the standard voltage? Well then based on what Andrei has said, yes.
[Galaxy S III Original Android Development] rlorange:
Well I'll be... works a charm with a body bias voltage of 1500mv I can UV 1800mhz step by 50mv! 1704 by 75mv!
[Galaxy S III Original Android Development] maazy:
For noobs like me, who uses default configs, is it worth updating to v36.1?
[Galaxy S III Original Android Development] Fienman:
Actually from what i understood. It is the exact opposite.

Increasing the slice voltage will require you more voltage to reach a said frequency, but it will decrease the voltage leakage.
[Galaxy S III Original Android Development] AndreiLux:
No.

Body bias = gate voltage - body voltage.

Take 1800 gate voltage = 1350mV for exmple.

Your default body voltage is 1300mV (example).

Your body bias is 1350mV - 1300mV = 50mV. You have a FBB of 50mV by default.

If you wish to be able to potentially reduce gate voltage, you need to lower body voltage.

If you lower gate voltage: 1250mV gate - 1300mV body = -50mV body bias. You're now applying a RBB, meaning you have now raised the threshold voltage of the chip. Basically you make it more power efficient but it'll probably crash because you worked against high clocks in both aspects.

If you lower your body voltage: 1350mV gate - 1100mV body = 250mV FBB. You lowered the voltage threshold of the chip, however you also increased the leakage. If you were already stable at that gate voltage, you achieved nothing by doing this other than increasing your power consumption.

If you lower your gate and body voltage: 1250mV gate - 1100mV body = 150mV FBB. You're still doing an FBB, however the bias is now higher than what you've started with. You still lowered the voltage threshold of the chip, but because you also reduced the gate voltage, you took advantage of it.

Because you're smart and educated, you realize that dynamic leakage caused by the gate at high frequencies is much greater than the static one affected by body voltage. You potentially reduced your total power consumption.

Well, in that case, it's defying the usual theory. It might be possible that the relation between gate voltage, frequency, and body voltage is a inverted bell curve. If you apply too much, you get negative effects, if you apply too little, you get negative effects.

In any case this will have users busy testing and trying to get a proper verdict for the next few weeks.
[Galaxy S III Original Android Development] habylab:
This is way beyond a smart and educated person like myself. I'll leave it to someone else to simplify.

Sent from my Galaxy S3. Long live the original Galaxy S :)
[Galaxy S III Original Android Development] Mimsy:
It seems I can run my ASV2 chip at very high RBB as I increased body voltage by 250 mV (I also have 100-112.5 mV UV across the board). So far no instabilities. Assessing the practical value (question is how much RBB actually helps battery life by reducing static leakage) of RBB is our current mission imo.

Second interesting thing is the overclocking potential achieved by FBB, it seems it works very nice for some people, but I haven't really got into it. Then we have GPU,MIF and INT ABB, which I'll leave alone for the time being as it could make troubleshooting impossible.
[Galaxy S III Original Android Development] rlorange:
Correction 1.8ghz was not stable at 1350mv...

Interestingly I raised the body voltage to 1400 from 1300 for slice 3 as well and my usual 100mv standard undervolt for all affected frequencies remained stable.

That's some big negatives there... so I guess this is good to cut power consumption.

Thanks for that explanation Andrei cleared that up nicely!
[Galaxy S III Original Android Development] cba1986:
After a factory reset i find out that my device is ASV3. Just in case i will hold my self for OC'ing in the time being. :D
[Galaxy S III Original Android Development] i9100g user:
Mine is asv 4 and -50mv(1350000uv) is stable for 1800mhz,with slice 4 at 1250mV(that should be a FBB of 100mV),already had 3 bootloops when i tried some other settings for 1800mhz :D,i will try more tommorow:)

This kernel keeps getting better :cowboy:

Thanks to AndreiLux;)

---------- Post added at 11:49 PM ---------- Previous post was at 11:44 PM ----------

Try flashing kernel again,it worked for me.
[Galaxy S III Original Android Development] cba1986:
Too late, but thanks anyways. :good:
[Galaxy S III Original Android Development] nfsmw_gr:
I have an ASV7 cpu,which runs 1700mhz@1400mV.

My body voltage is 1300mV.

If i want to lower the consumption i should lower the cpu voltage and the body voltage?

1300mV - 1250mV = 50mV FBB which is good?

Also two questions.

Gate voltage is the same as cpu voltage?

The same theory applies to gpu too?
[Galaxy S III Original Android Development] rickoslyder:
I'm on AOSP, but since Temasek kernel is basically Perseus on AOSP it shouldn't be much of a difference.

EDIT - 1800 MHz frequency results in bootloops for me. My phone couldn't generally support them before anyway, but post edited anyway.
[Galaxy S III Original Android Development] i9100g user:
So above 1600 mhz , you are experiencing boot loops right? Because those FBBs(for 1704 and 1800) are lower than default FBB of 100mV.
[Galaxy S III Original Android Development] coolnessQ:
Guys what are recommended settings for long batterij and performance? Or do i have to switch to speedmod?

posted by the Q Master, woepidooo
[Galaxy S III Original Android Development] rickoslyder:
I haven't tried clocking it to 1800, will try now.
[Galaxy S III Original Android Development] cba1986:
My device is asv3 and before alpha36 i could run at 1704 @ 1300mv. But now even at stock voltages my phone reboots. :(
[Galaxy S III Original Android Development] Mimsy:
Default settings have best performance/battery ratio.

[MENTION=3569077]rickoslyder[/MENTION], if I'm correct, you are using FBB for 200 MHz step (Slice 1: 700mV), which makes no sense as you are increasing leakage on idle clocks. Low clocks should have high RBB as static leakage is much lower, it is also dictated by the Sammy chart in the OP.

EDIT: I suggest people read Andrei's posts thoroughly. They contain all the info and offer very nice explanation. If you don't get it, read it again. It's impossible for developer to collect data and find proper feedback, if all he has to read are questions of people that can't be bothered to read OP and use search button.
[Galaxy S III Original Android Development] i9100g user:
Read this thread again, read OP and Andrei's last post, should answer most of your questions;)

Edit:nvm
[Galaxy S III Original Android Development] nfsmw_gr:
Well,i did.

I'm just asking for confirmation.A yes or a no. :)
[Galaxy S III Original Android Development] i9100g user:
If you want to reduce power consumption (or reduce power leakage) then you would want to increase your RBB, but remember that could cause instability at higher clocks.

And read whatever is given in this thread, I have understood these things from this thread only, not from any other source.

OP already provides enough information.
[Galaxy S III Original Android Development] habylab:
So reducing my gate voltage to 750mv, a 50 decrease, and my body voltage to 800 from 1000 would not save battery? As in, I should of kept the body voltage at 1000? Doing so would have a higher RBB. I hope I'm right!

Sent from my Galaxy S3. Long live the original Galaxy S :)
[Galaxy S III Original Android Development] lucianolsp:
Hi guys,

I have a problem which I think is related to the kernel.

I use "white noise" software to sleep every night. This software plays a sound loop constantly during the night. The problem is that, whatever software I use, after a couple of hours (approx) the sound becomes choppy, as if the phone entered a deeper sleep state and is unable to provide enough processing power to the software. After I press the home button, it usually resumes playing fine (but then I´m already awake :( ). The phone is pluged on the eletric power during the night.

Anybody could give me some hint on how to solve this very anoying issue??

Thanks a lot!

Luciano
[Galaxy S III Original Android Development] habylab:
Could be the app, you never know. Raise voltage for lower frequencies or raise minimum frequency to see if that helps.

Sent from my Galaxy S3. Long live the original Galaxy S :)
[Galaxy S III Original Android Development] i9100g user:
You can try that , but be ready to face crashes anytime, as it could be unstable.
[Galaxy S III Original Android Development] habylab:
Theoretically though, 1000 would be better for first slice, I assume?

Sent from my Galaxy S3. Long live the original Galaxy S :)
[Galaxy S III Original Android Development] cba1986:
I raised slice 4 body voltage from 1000 (default) to 1200 now i can run 1.8 @ 1400 (stock voltage). When before crashed almost immediately.

EDIT: testing 1350 body voltage.
[Galaxy S III Original Android Development] habylab:
Interesting, good progress.

Sent from my Galaxy S3. Long live the original Galaxy S :)
[Galaxy S III Original Android Development] cba1986:
If well the 1800 now works had proven to be quite perfomance unstable. For example 10000 one minute and 15000 the next one (Antutu). Perhaps the gate voltage limit is affecting stability. (But, what would i know?)
[Galaxy S III Original Android Development] AndreiLux:
If it's unstable it crashes, period. You're probably hitting thermal throttling limits.

By the way: It would be also interesting if people would try to play around with the standard higher frequencies (Slice 3) to see if they can manipulate it as such to enable better gate undervolting.
[Galaxy S III Original Android Development] Kyle07:
Antutu Benchmark results have varied radically for me for a while now. At times I can get 16500 and then, a few minutes later, with the same settings I'll get a measly 8000. I'm not sure that Antutu (or any benchmark for that matter) is an effective way to measure performance improvement. I, personally, feel the performance improvements during everyday use and that is all I want.
[Galaxy S III Original Android Development] nfsmw_gr:
I'll try,as soon as i absolutely understand the mechanism and post back the results.

+1

I agree mate,most of benchmarks are pointless regarding real life use.
[Galaxy S III Original Android Development] FD10:
With 36.1, the led shows all colors correctly except orange
[Galaxy S III Original Android Development] Kyle07:
I must agree with habylab with regard to the increasing of the voltage of the lower frequency steps. I have an ASV4 chip but the 200MHz step seems to be borderline stable with the accompanying tabled voltage. Giving a 50mV over-volt at the 200MHz step has eliminated the audio stutter for me.
[Galaxy S III Original Android Development] mattiadj:
Can anyone tell me how can I increase the wireless recharge power from 499mA to 999mA?

It's possible? With latest yank kernel I can and it's very useful. Is possible with this also?

From universe with my gs3
[Galaxy S III Original Android Development] fknpwned:
How to find out the ASV Group?

The file /sys/devices/system/abb/abb_info doesnt exist.

Only three folders in sys/devices/system. Clocksource, CPU and Exynos4Core.
[Galaxy S III Original Android Development] psyntific:
In GPU for example.. does SLICE 3 include the 533MHz or is 533MHz a part of slice 2?
[Galaxy S III Original Android Development] Erahgon:
Not yet possible in this kernel.

Update to the latest version of the kernel (v36+).

Sent from the present, which is now in the past.