Database Develop

[APP] [9/7] Proton Voltage Control v1.3 | Easy UV for Netarchy and Matr1x Kernels

{
"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"
}
Version 1.3 [Released 9/7/11]​
Proton Voltage Control is an easy to use app that allows you to set custom voltages for Nexus S phones running a supported version of Netarchy and Matr1x kernels (1.3.0.6 for Netarchy and 4.0 for Matr1x and up) This means you no longer have to muck around with command line codes and scripts, just one easy to use app!
I am a busy highschool student, with no solid income. If you like my app, please consider a donation
Click to expand...
Click to collapse
Downloads
Update 16/9/11: Due to requests, I have built 1.3 again but with a different release key. Please UNINSTALL any old version before installing!
Version 1.3 ProtonVoltageControl-130.zip
Emergency Restore: proton_emergency_boot.zip
Usage
Enter in your new voltages in the 8 text boxes, or use one of the 3 buttons at the top to give you a base to try.
Hit Apply to set temporarily, and see how the voltages perform. If you reboot at this stage, the new voltages will be lost
If these new voltages work well on your phone, enter them in again and this time check 'Save on Boot' then hit Apply. These voltages should be applied upon startup every time now
Easy!
- It is easier to press one of the 3 voltages buttons to give you a base to work on
- The suggested voltages is mostly -20mV on all frequencies (from stock voltages) except for 1.4ghz and 1.3ghz which have been raised ever so slightly
- 'Save on Boot' creates an init.d script called proton_voltage_control with your entered values, so don't be alarmed if you see an extra init.d script
- Press Menu and Emergency Boot Zip to download a flashable update.zip to remove any 'Save on Boot' files in case you can't boot up due to setting the voltages too low. Boot into Recovery and flash like any other update.zip
Enjoy! Please ask if you have any questions, I will try to help with them. Standard disclaimer applies, I claim no responsibility for anything that goes wrong with your phone due to misuse of this app.
Also on the Market! https://market.android.com/details?id=com.jonathongrigg.proton.voltagecontrol
Proton Voltage Control is fully open sourced
Source is available at my Github, https://github.com/jonathongrigg/ProtonVoltageControl
Credits
Jonathon Grigg
Spiicytuna [New UI overhaul]
Xan [Original Galaxy S app which gave me inspiration to write my own from scratch for the Nexus S]
'Serge' (from MarketEnabler I believe) [ShellInterface code]

Donators
Tord Persson
Should work on all Nexus S models (including the 4G)
Sent from my Nexus S

Can I request custom settings save profile? In case something doesn't work you might want to go back to a profile and change things around.

Using it, and loving it so far
Sent from my Nexus S using XDA App

Good App. I will buy Pro Version if you publish one in the market.
Sent from my Nexus S using XDA Premium App

Had been using script manager with custom scripts to get settings loaded on boot, but have deleted them to use this
Really like the app, can't wait for UI improvements (even though it is fully working now).
Get this thing on the Market with a pro version!
Edit: Jonathon, maybe you could go in depth a tad more on usage , just for the moment because people new to UV may be confused what it does and how it works exactly

thanks dude, it's awesome! I've been waiting for an app like this to UV netarchy's kernels!
i'm running CM 7.0.3 with netarchy's 1.3.2, just did a -50mV across all frequencies and it has been working very well.

Please forgive my ignorance... but what exactly can be obtained by altering voltages??
Better battery life etc?

Thanks for the UI for UV'ing! It makes life so much more easier than typing on terminal.
One concern though, my settings are not saving on reboot. I'm running SuperAOSP 8.0 with Netarchy 1.3.0.12 CFS 2.3.4 Universal and after entering my desired values and checking Save on Boot, upon restart the app reads back the default voltages again (1450 etc...).
The program does state that it saves it to init.d but other than that it doesn't save it. Am I doing something wrong or am I supposed to re-enter values everytime i make changes to my phone that requres a reboot, which is a lot considering i try out a lot of the ROMs out there often.

Dario777 said:
Please forgive my ignorance... but what exactly can be obtained by altering voltages??
Better battery life etc?
Click to expand...
Click to collapse
Better battery life and lower temperatures.
Sent from my Nexus S using XDA Premium App

jello24 said:
Thanks for the UI for UV'ing! It makes life so much more easier than typing on terminal.
One concern though, my settings are not saving on reboot. I'm running SuperAOSP 8.0 with Netarchy 1.3.0.12 CFS 2.3.4 Universal and after entering my desired values and checking Save on Boot, upon restart the app reads back the default voltages again (1450 etc...).
The program does state that it saves it to init.d but other than that it doesn't save it. Am I doing something wrong or am I supposed to re-enter values everytime i make changes to my phone that requres a reboot, which is a lot considering i try out a lot of the ROMs out there often.
Click to expand...
Click to collapse
Do you have super user set up properly? Clear permissions from the app and try again
Sent from my Nexus S using XDA App

Thanks for this. Great app, makes it very easy.
Sent from my Nexus S running NSCollab, Cyanbread Theme and OC'd to 1.2ghz (Perfection)

Great app! Definitely saves time when tinkering with the voltages.. Thanks!

Has anyone tried this with default kernel from superaosp 8.2? It looks very similar to netarchy....
Also any recommendations for voltage levels?
Sent from my X10i TripNMiUI-IRIS using XDA App

can you add support for trinity kernels?

shubu000 said:
Has anyone tried this with default kernel from superaosp 8.2? It looks very similar to netarchy....
Also any recommendations for voltage levels?
Sent from my X10i TripNMiUI-IRIS using XDA App
Click to expand...
Click to collapse
Voltage levels will depend on individual phones, some will go lower while others would bootloop so low (good idea to not use set on boot to start with until you've tested it for a bit). There is a suggested voltages button in the app which is -25mV across all 8 frequencies as a starting point. Most phones should be able to handle this, but there are a few exceptions.
Sent from my Nexus S

The only two reasons why you would want to decrease or under volt (UV) set your frequencies is to save battery and extend your processor life expectancy.
The only reason to to increase or over volt (OV) your frequencies is to get a higher clock speed on your processor. Some phones will not handle the default setting and need extra voltage for transistors to get a better and cleaner signal.
This is very much the same principle as in any desktop PC. You increase voltage to be able to overclock but if you have a good quality fabrication, ie later production processor or maybe manufactured in a different fabrication facility you might be able to get away with less voltage which in effect lowers your battery usage. You could also achieve the same by better cooling, but unless you expect to keep ice on your phone, this doesn't really make sense.
To dig deeper into the matter, as far as I understand, when higher clock speeds are requested of a processor, transistors give away more heat. This in turn will also swell them up and they will start to short from one to another and/or loose current flowing through them. Another effect is the slowing down of the transistor gate on/off. All these conditions may trigger an error and in some cases a major freeze of the processor.
There... a quick explanation to have this app available.
BTW, we should also thank Netarchy for making such settings available in his kernel. Cheers

jello24 said:
Thanks for the UI for UV'ing! It makes life so much more easier than typing on terminal.
One concern though, my settings are not saving on reboot. I'm running SuperAOSP 8.0 with Netarchy 1.3.0.12 CFS 2.3.4 Universal and after entering my desired values and checking Save on Boot, upon restart the app reads back the default voltages again (1450 etc...).
The program does state that it saves it to init.d but other than that it doesn't save it. Am I doing something wrong or am I supposed to re-enter values everytime i make changes to my phone that requres a reboot, which is a lot considering i try out a lot of the ROMs out there often.
Click to expand...
Click to collapse
bringonblink said:
Do you have super user set up properly? Clear permissions from the app and try again
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
yeah SU was set up to allow the UI to work, but I cleared that permission and ran the program again allowing it to go but it still won't save on boot. Existing voltages always show the default, instead of my desired settings.
I even tried it where i'd have to keep clicking allow on SU to get it running but it still won't save.
any other suggestions?

jello24 said:
yeah SU was set up to allow the UI to work, but I cleared that permission and ran the program again allowing it to go but it still won't save on boot. Existing voltages always show the default, instead of my desired settings.
I even tried it where i'd have to keep clicking allow on SU to get it running but it still won't save.
any other suggestions?
Click to expand...
Click to collapse
Can you try the 'cat' command to list the voltages in Netarchys thread and see if its the same as the existing voltages shown in Proton.
Sent from my Nexus S

jello24 said:
Thanks for the UI for UV'ing! It makes life so much more easier than typing on terminal.
One concern though, my settings are not saving on reboot. I'm running SuperAOSP 8.0 with Netarchy 1.3.0.12 CFS 2.3.4 Universal and after entering my desired values and checking Save on Boot, upon restart the app reads back the default voltages again (1450 etc...).
The program does state that it saves it to init.d but other than that it doesn't save it. Am I doing something wrong or am I supposed to re-enter values everytime i make changes to my phone that requres a reboot, which is a lot considering i try out a lot of the ROMs out there often.
Click to expand...
Click to collapse
I think I might know what your problem is. You have to hit apply after you select set on boot, otherwise it won't save the changes.
I didn't realise this the first time either!!!

Voltage Control - control OC/UV for OC kernels.

I take no responsibility for ANY damage / data loss may occur. Use this at your own risk. Beta quality software!/Alpha quality features!
The news:
Completely rewritten whole app! Epic 4G FCs gone thanks to theimpaler747
Voltage Control Extreme unlock Key on Android Market!
For now features exclusive to Extreme version are:
+ overvolting capability (max +50mV, 1500mV absolute maximum)
+ increased uv range (max -250mV)
Click to expand...
Click to collapse
Sources available, project on google code:
http://code.google.com/p/voltage-control/
Look for kernels with this label:
Kernel developers who added VC support please show this image in your topic
{
"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"
}
Uploaded with ImageShack.us
Features:
- minimum/maximum CPU frequency choosing
- selecting IO scheduler
- selecting CPU governor
- changing voltage per frequency
- chosing which frequencies should be used and which shouldnt
- saving settings to be automatically applied at boot (init.d script)
- saving/loading a OC profile
- well designed and highly optimised UI (I hope..)
- robust kernel detection, support of not-so-well-working kernels
About donations:
This software is available free of charge.
It cooperates with OC kernel by raspdeep.
It uses some code from: MarketEnabler (Fool your market to make all apps visible!)
If you find this software useful, please consider funding a beer and pizza. There is a "Donate to me" link just over my avatar.
Donator list:
nitr8
kalpik
laststufo
glitterballs
screwyluie
Gembol
Coreym
Thanks!
How to?
Generally idea is simple: make changes to one tab and hit apply. If any changes have been made apply/discard buttons appear on bottom.
The first tab, "General" allows to change Scheduler,Governor/min and max frequencies.
Make changes and click apply
So, you want to pick a maximum/minimum frequency?
Just chose from slider and hit apply.
Governor/scheduler can be choosen by picking from the list, then hitting apply.
You can always discard changes before applying if you want start from loaded settings.
The "Advanced" tab has sliders to control undervolting settings and green/red icons, representing enabled/disabled state.
(green = enabled, red = disabled)
Pick your settings and hit apply, or discard and start over.
Profile support:
If you want to save as boot or as profile, you need to make adjustments and on "General" or "Advanced" tab and then apply them where applicable.
To save as boot -> press menu key, then select "Save as boot settings".
To save as profile -> press menu key, then select "Save profile".
Boot settings are automatically loaded on every device boot.
Profile settings can be loaded by pressing menu -> "Load profile"
Both "boot" and "profile" settings can be deleted from menu.
RECOVERY
If Your device freezes after boot because of too agressive boot settings:
Flash Voltage Scheduler Remover by user Coreym, via CWM. Don't forget to press thanks under one of his posts!
FAQ:
Q: Extreme version?
Yes, I wanted to give some extras for people that support my work.
For now features exclusive to Extreme version are:
+ overvolting capability (max +50mV, 1500mV absolute maximum)
+ increased uv range (max -250mV)
Q: What is it?
Its voltage control app for undervolt and overclocking kernels providing sysfs interface, designed and implemented by raspdeep (thank You!) It is being tested on his kernel releases and I can guarantee (kind of) its functionality on those kernels.
The idea of the app is to keep all simple as possible, not adding any startup services and reusing existing solutions (such as init.d support).
Q: What does it mean to undevolt, and what is overclocking?
Read more in "OC / UV 101" section That is a detailed(sort of) explanation what UV/OC means.
Check this great overclocking/undervolting guide by shaolin95 (thanks!) and discussion topic!
Prerequisites:
-root (superuser + su)
-busybox
-OC kernel supporting either UVLF and UVHF (Version 1.61) or UV_mV_table (1.97 and up)
-init.d scripts support for apply on boot

xan said:
Hi I've seen some reports on market that new version is broken on Epic4g. Anybody knows whats goin on?
Logcat output welcome.
Click to expand...
Click to collapse
First!!!
I tried it with the Bonsai Rom a couple of days ago and it worked for me. I purchased the extreme and I undervolted straight across the board 250mv and I have no problems so far. I think it all depended if the kernel on the phone is compatible or not.

xan said:
Hi I've seen some reports on market that new version is broken on Epic4g. Anybody knows whats goin on?
Logcat output welcome.
Click to expand...
Click to collapse
It made me smile when I saw that you posted. Taking a personal interest and such.
I think you might be getting reports from Syndicate people. Syndicate's Twilight kernel didn't implement sysfs very well. Voltage Control will recognize it but changes can't be made and some clocks aren't read correctly. PimpMyCPU won't read it all.
Genocide kernel, Vision kernel, and Bonsai's kernels all work flawlessly.

Thanks
This rewrite costed me *a lot* of work seeing 1 star ratings on market makes me sad ;p

I'm using twilight kernel without any problems but I'm no longer on SFR anymore.
Sent from my SPH-D700 using Tapatalk

xan said:
Thanks
This rewrite costed me *a lot* of work seeing 1 star ratings on market makes me sad ;p
Click to expand...
Click to collapse
Yeah, that's not right. My Epic doesn't play nice with Voltage Control but I know better than to rate the app bad. These Epics each have a mind of their own. Some like undervolting, some dont. Some like certain ROMs better. I can run 1400 all day but no undervolting for me
Sent from my SPH-D700 using XDA Premium App

FCS on some kernels fixed ;p
Thanks going to theimpaler747, for detailed bug report and testing

I have found multiple issues with the Twilight kernel, I love the rom, just Genocide has been a lot more stable AND I never had any issues with Voltage Control. I was wondering if you might incorporate multiple profiles like SetCPU? I had to start looking for a different program when it would constantly lock my phone when trying to use them and then I found Voltage Control, and after the rewrite it just makes it that much easier to use.

This might be good, true.
Multiple profiles seem doable...

xan said:
FCS on some kernels fixed ;p
Thanks going to theimpaler747, for detailed bug report and testing
Click to expand...
Click to collapse
Happy to have helped out for a great app!

hey all, im running SFR 1.1.1 with its stock twilight kernel.
i use to run genocide, but i think i messed up with the UV features and i started getting a lot of lockups. right now i just run setcpu with 1300/400 and i seem to be ok.
i think i bought the WRONG voltage control app also. i bought voltage control extreme by sulph8.
i would love to get back to 1400/400, but im really unsure what the best course of action is. are there default voltage settings in this app? initially, i'd like to run 1400/400 with all the standard voltage settings to see if my phone acts normally again.

Well, Voltage Control by nitr8 is a unlock key for 'mine' voltage control. For now all money goes to him, he promised to send it to me.
To revert to stock settings -> Chose delete boot settings and reboot.
Viola, you have booted on stock settings!
Then set desired frequency limits and you are done

so i should set my setcpu back to 1000, remove setcpu, flash genocide kernel, install your voltage control and start from there?

Sounds ok

what should i set my governers to?

Well, depends on your experience with kernel, generally:
For battery saving try conservative.
For reasonable performance try interactive/ondemand or smartass.
Some kernels have bad implementation of some governors, which can make them unstable, so you need to test, test, test and observe
From my experience smartass (where implemented) is very smooth.
Stock Samsung Gingerbread kernels came with ondemand (not entirely sure)
Stock Froyo/Eclair was conservative.

useport80 said:
so i should set my setcpu back to 1000, remove setcpu, flash genocide kernel, install your voltage control and start from there?
Click to expand...
Click to collapse
Well, I just flashed it again on Genocide. I am running 1400/200 on demand. I am going to check CPU Spy to see if it performs similar to SetCPU. Curious if on demand still drops below 200 if its set as my minimum like Set did
Sent from my SPH-D700 using XDA Premium App

Voltage Control doesnt use any "hacks" for setting frequencies, it just works with standard implemented sysfs.
The governor is responsible for respecting max/min frequency, its kernel implementation that should keep CPU running within desired freqs.

Can the UI include a CPU temp and aninfo page?
Sent from my armed and operational battle station.

SGS's only thermal monitor is refferred as "battery"...
Info page is somewhat coming, but I have to be sure what and how to put there.

[krn.modules] overclocking for Arc (ICS) without custom kernels [now released!]

Update:
Use at your own risk, nothing is guaranteed!! Overclocking is dangerous and could brick your phone so be aware of what you are about to do!
If you want to take the risk, the files are below:
overclock_arc_ics_v1.zip
Install procedure:
1. The zip contains two files, overclock_12.ko and overclock_14.ko.
2. Unpack the two files onto your /sdcard folder
3. Insert one or the other using:
Code:
insmod /sdcard/overclock_1X.ko
where X is 2 or 4 depending on what frequency you want, 2 for 1200MHz or 4 for 1400MHz.
You can create a small script with the same contents and have Script Manager run it at boot time.
IMPORTANT: About frequency managers:
The CPU Managers are not perfect (I've tried SetCPU and No Frills).
They do not read the frequency tables from kernel - but as far as I can tell, they rely on the time_in_state file to see what frequencies are available. But if a frequency is changed, they remain disorientated.
THUS.
a) When booting the phone with any of the overclocking module there should be no problems, as long as SetCPU / NoFrills did not start and did not read the time_in_state file. Then no changes needed.
b) But if you start them and THEN you insert / remove the modules, etc - please go back to them and select again minimum frequency and maximum frequency EVEN IF they appear as already selected.
Just drag the first slider to the max and the second one to the min.
Also IMPORTANT:
Do not set the module at boottime unless you are absolutely sure the phone is stable with the frequencies. Otherwise you might end up in a boot loop.
PS: To other members trying to help: PLEASE DO NOT REPACK the archive and to offer it as update.zip or init.d scripts, etc.
I will do it in the next few days. The reason is that people get confused what to choose and then they ask questions about those .zips and so on. Better keep things simpler with minimal changes to the system (even these modules, they are very small, ~30kb ).
Enjoy guys - and thank you very much for your support!
Do not forget: for anyone interested, I posted a lengthly tutorial on my blog on how overclocking is achieved (disassembly and so on): http://hex.ro/wp/blog/overclocking-an-android-phone-running-with-an-msm-core/
--
I've managed to overclock my Arc (running Arc S latest ICS ROM) to run at 1200Mhz - all this WITHOUT a custom kernel and without the bootloader unlocked and so on.
I've read oppinions like this one: http://talk.sonymobile.com/message/184828#184828:
To Overclock you need to use a custom Kernel[ DoomKernel]. with Stock kernel overclocking not possible. To use a custom kernel you need to unlock the bootloader. [which is little bit sensitive]
Click to expand...
Click to collapse
This is plain wrong.
I will offer the module, but now is still in development, since the time_in_state table is still wrong (but that doesn't mean CPU doesn't go to 1200Mhz with any governor installed). Also, I don't know if I will ever fix the time_in_state since it is boring to disassemble - but it can be done.
Here are some screenshots:
1) Running at 1200MHz, but SetCPU insists the maximum frequency is 1024MHz - it probably uses some other values instead of the one on the /sys/devices/system/cpu ..
{
"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"
}
2) SetCPU Native Benchmark (at 1200Mhz it is around 600, and at 1024MHz it is arround 800 - lower is better)
Although things could have been easier if the kernel would export some symbols - nonetheless it can be done by using the /proc/kmem dump in a similar process described here http://code.google.com/p/milestone-overclock/wiki/Disassembly (but adapted to msm instead of omap2).
I will post a full article too - but I have to write it first - on how to do this...
If you guys are interested or having any questions, just post below ..

Great project man. o:
Btw how's the work coming along on those flashable modules ? Cause module loader loads the module randomly in the middle of a game and it gets stuck. :/

WOW.
please work on these..
i am on locked bootloader and dying to overclock.
do it. go go vulian
---------- Post added at 10:36 AM ---------- Previous post was at 10:35 AM ----------
i want my arc to have cpu values that of an arc s.
oc to 1.4g with same cpu states as that of arc s.
my device is ready for testing. waiting for guide.
---------- Post added at 10:40 AM ---------- Previous post was at 10:36 AM ----------
+1000
please do it.
---------- Post added at 10:56 AM ---------- Previous post was at 10:40 AM ----------
i read the article. most of it went above my head. i understood few things though.

Nice try mate!
But why 1200 and not 1400Mhz like by default in Arc S?

thanks for the support guys
I did not try to go to 1.4 Ghz since I believe I need to up a bit the voltage and I did not yet identified kernel memory spaces where this has to happen.
I'm still looking to see if time_in_state can be adjusted - the table seems dynamically allocated and it makes its detection a bit more tedious since it doesn't have a fixed address in memory upon each reboot.
I'm wondering if it is needed to know what time in state is, seems more useful for battery saving but since the goal is to overclock ..

Good news - time in state table is fixed.
Noticed a few glitches with the time_in_state programs (mostly SetCPU).
Since the phone starts with 1024MHz but then is changed by the module to 1200MHz, some programs have small bugs because they remember the initial frequency. For example, after module is inserted, SetCPU somehow considers the minimum frequency to be 245MHz but a touch of the slider makes it go back to 122MHz.
This is now the only small inconvenience ..
Also, the smartassV2 module I've built has the max frequency set to 1024MHz, but I will recompile and offer them as a bundle to have 1200MHz hard coded. It is actually faster to have the speeds hardcoded instead of detected on the fly, since it makes the transitions quicker ..
Below few screenshots:
a) SetCPU showing correct Max frequency.
b) CPU Spy showing time in state ... it uses also deep sleep.
c) SetCPU bogomips:
One last thing...
I cannot add all Arc's S frequencies. It is easier to 'patch' the kmem and have the phone go to 1200MHz instead of 1024MHz instead of adding new values - because time_in_state table is allocated dynamically when phone boots to have 6 states. There's no space allocated for additional frequencies. If I add another value at the end (and patch the indexes) - some other variable put there by the kernel could be overwritten.
I could allocate the table in the module and update the global pointer to the new space - but it means more code which now doesn't seem necessary.
I will do some tests with 1400 instead of 1200 ..

keep going...
waiting for your release.
finally oc.
---------- Post added at 10:14 AM ---------- Previous post was at 10:11 AM ----------
not a worry for not implementing all Arc s frequencies.
in first hand, get this working..
thanks for hard work

VICTORY!!!
First, for happy side, here are the benchmarks:
a) AnTuTu 3373 vs 3069 (about 10% increase according to it).
b) Linpack 38.05 vs 33.5
Second, for drama side:
SetCPU native results from the initial posts above ended up to be fake. Don't know what SetCPU was doing but were incorrect. I'll explain.
Wanting to put some screenshots of OC improvements, I tried out Antutu and linkpack. To my surprise / shock, they were both offering the same values for the two speeds, 1200MHz and 1024MHz. I could not believe, how come the speed was now 1200 but results the same ???? Also, SetCPU did report an massive improvement, right ? From 800 down to 600 ...
Unconvinced, I found a PI Calculator, and tried it out with 10000 digits, it also reported same results 10.3 seconds .....
So ... going back to the source code I found out that frequency was actually controlled by the PLL rates and I was not modifying those, the CPU was actually phisically running at 1024Mhz. I lost trust in SetCPU with it's native tests (which now return about 500 when I finally fixed the code).
I thus dug more and found the correct PLL rates - and changed them to the real 1200MHz. Indeed the phone switched to the correct frequency and all performance tests above show the increase.
Tests were done with Performance governor on (max speed).
PS: PI Calculator now reports 9.3 seconds for 10.000 digits, and improvement of 10%.
I will release the module very soon now.

Hurray!
waiting for module and guide on how to implement it...
---------- Post added at 02:20 PM ---------- Previous post was at 02:19 PM ----------
btw, this time I understood some of drama part.
improvement.

It will be very simple - just:
Code:
insmod overclock.ko
To run it at boot time, it can be done from GUI using apps as Module Loader or Script Manager (SManager).

viulian said:
It will be very simple - just:
Code:
insmod overclock.ko
To run it at boot time, it can be done from GUI using apps as Module Loader or Script Manager (SManager).
Click to expand...
Click to collapse
or use install-recovery.sh which works like init.d folder

viulian said:
VICTORY!!!
First, for happy side, here are the benchmarks:
a) AnTuTu 3373 vs 3069 (about 10% increase according to it).
b) Linpack 38.05 vs 33.5
Second, for drama side:
SetCPU native results from the initial posts above ended up to be fake. Don't know what SetCPU was doing but were incorrect. I'll explain.
Wanting to put some screenshots of OC improvements, I tried out Antutu and linkpack. To my surprise / shock, they were both offering the same values for the two speeds, 1200MHz and 1024MHz. I could not believe, how come the speed was now 1200 but results the same ???? Also, SetCPU did report an massive improvement, right ? From 800 down to 600 ...
Unconvinced, I found a PI Calculator, and tried it out with 10000 digits, it also reported same results 10.3 seconds .....
So ... going back to the source code I found out that frequency was actually controlled by the PLL rates and I was not modifying those, the CPU was actually phisically running at 1024Mhz. I lost trust in SetCPU with it's native tests (which now return about 500 when I finally fixed the code).
I thus dug more and found the correct PLL rates - and changed them to the real 1200MHz. Indeed the phone switched to the correct frequency and all performance tests above show the increase.
Tests were done with Performance governor on (max speed).
PS: PI Calculator now reports 9.3 seconds for 10.000 digits, and improvement of 10%.
I will release the module very soon now.
Click to expand...
Click to collapse
speak ENGLISH. lol. i can't understand, but, where is the overclock.ko? hehehe

The overclock.ko will come in two flavours
One for 1200000Hz another one for 1401600Hz.
I have posted an article on my blog on the procedure followed to create the module: http://hex.ro/wp/blog/overclocking-an-android-phone-running-with-an-msm-core/
I've tested the 1.4Ghz frequency with 1200mV voltage and it resets in Antutu towards the end of the 3D test. However, I've upped the voltage to 1250mV and I've ran 3 Antutus with no problems! But boy it gets hot.
Here are some benchmark results from 1024000Hz up to 1401600Hz
a) 37% in CPU Integer operations
b) 41% in CPU Floating Point operations.
This generates almost 20% increase in total performance!

viulian said:
I've managed to overclock my Arc (running Arc S latest ICS ROM) to run at 1200Mhz - all this WITHOUT a custom kernel and without the bootloader unlocked and so on.
I've read oppinions like this one: http://talk.sonymobile.com/message/184828#184828:
This is plain wrong.
I will offer the module, but now is still in development, since the time_in_state table is still wrong (but that doesn't mean CPU doesn't go to 1200Mhz with any governor installed). Also, I don't know if I will ever fix the time_in_state since it is boring to disassemble - but it can be done.
Click to expand...
Click to collapse
its very much possible...
if u have the time to get it working, here is MSM7x30 specific module for this type of overclock:
https://github.com/coolbho3k/vision_oc
viulian said:
The overclock.ko will come in two flavours
One for 1200000Hz another one for 1401600Hz.
I have posted an article on my blog on the procedure followed to create the module: http://hex.ro/wp/blog/overclocking-an-android-phone-running-with-an-msm-core/
I've tested the 1.4Ghz frequency with 1200mV voltage and it resets in Antutu towards the end of the 3D test. However, I've upped the voltage to 1250mV and I've ran 3 Antutus with no problems! But boy it gets hot.
Here are some benchmark results from 1024000Hz up to 1401600Hz
a) 37% in CPU Integer operations
b) 41% in CPU Floating Point operations.
This generates almost 20% increase in total performance!
Click to expand...
Click to collapse
just saw this
nice work with the how-to on the blog...

Thanks for the link.
I've checked it but is incomplete - it doesn't handle the time_in_state file ( cpufreq_stats_table kernel variable).
Mine goes on a similar route but :
a) handles the time_in_state
b) is unloadable (which the vision_hc doesn't do - it doesn't go back to stock if you want rmmod it). Mine switches back to stock.
But a good effort on that one also!
Will put them up tonight.

very nice, really looking forward the release to try it

Is it possible on the ARC S too ? Maybe 1.6 Ghz ?

@Dark Fable - About the Arc S - I could but I need remote access to a phone to be able to dump specific addresses into memory and adjust the constants from the code.

tRippinthehead said:
or use install-recovery.sh which works like init.d folder
Click to expand...
Click to collapse
How do you use install-recovery.sh to boot modules?
Sent from my SO-01C using xda premium

Thanks Vuilian.
i want to implement this.
what is to be done?
i find no modules in here.

[krn.modules] smartassV2 governor for Galaxy S3 stock Kernel

I've FINALLY managed to compile smartassV2 module for SGS3's stock kernel.
{
"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"
}
The trouble is that the stock kernel does not accept modules...
Every attempt I made ended up with an error about the version of module_layout. I even wrote to Samsung asking for clarification, but I have no reply yet (after about 24 hours).
I will write a post on my blog describing all the investigations; I had to go the hard way and patch /dev/kmem to skip the validation. I've created a small executable which does this.
The good part about it ? It is already included in the .tar.gz below and once executed, it allows any modules to be installed on stock!
I am almost sure that Samsung did not provide the up to date .config file (I am using the Update 1 .tar file) since I had to disable flags in .config to get rid of "unknown symbol" errors. And another proof, the validation errors related to the version of the module_layout symbol.
Thus, the install procedure is a one step longer, patchs3k needs to be executed once, and then any module can be inserted.
Installation procedure:
a) mount your /system in RW mode.
b) create folder /system/xbin/lib
c) copy the contents of the archive to that folder.
d) execute the provided load_smartassV2.sh script (which already does all the steps: calls patchs3k, inserts the module and sets it as current governor).
That's it!
Observations:
a) only for stock kernel.
a1) repeat after me: I will not attempt to run patchs3k if I already flashed a different kernel!
b) load_smartassV2.sh script is made so it is also runnable by Script Manager at boot as super user using the paths in the Install procedure.
c) if you have another way of loading things, you need to figure out how to execute the patchs3k file before inserting the module - I found that the easiest is with the method above.
d) smartassV2 supports lots of configuration options. The only think I made default is the ramp up increment, which is in 500MHz so you don't have to wait forever until the phone gets to max speed. The ramp down I left it at 100MHz increments. All these are configurable and you can echo values in the files found in the list below.
A brief description of each field (but with different values since back then I did it for Sony X10) is found in the Settings part of this post: http://forum.xda-developers.com/showthread.php?t=1212012
Code:
[[email protected]]/sys/devices/system/cpu/cpufreq/smartassV2# ls -1
awake_ideal_freq
debug_mask
down_rate_us
max_cpu_load
min_cpu_load
ramp_down_step
ramp_up_step
sample_rate_jiffies
sleep_ideal_freq
sleep_wakeup_freq
up_rate_us
Download:
Update: download disabled until hotplug issues will be fixed! Please check 4th post below, thanks AndreiLux!
Use it at your own risk!
cpufreq_smartass2_sg3_1.0.tar.gz
Enjoy!

Im really interested in the part regarding the patch to use any module without validation...
Waiting for kernel patch
Sent from my Desire HD using Tapatalk 2

The patchs3k is already bundled in the .tar.gz file above - is this what you meant ?

There's absolutely no point in having smartass on this device, especially on a stock kernel since there is no remaining hotplug logic on it to be used, if that would be even possible. It has major detrimental effects on battery life.
However, we would be interested in what you are doing inside of patchs3k to make it load the module properly and to see if we can use any of that to load Samsung's exFat driver module on custom kernels. Sources please?

viulian said:
The patchs3k is already bundled in the .tar.gz file above - is this what you meant ?
Click to expand...
Click to collapse
AndreiLux said:
There's absolutely no point in having smartass on this device, especially on a stock kernel since there is no remaining hotplug logic on it to be used, if that would be even possible. It has major detrimental effects on battery life.
However, we would be interested in what you are doing inside of patchs3k to make it load the module properly and to see if we can use any of that to load Samsung's exFat driver module on custom kernels. Sources please?
Click to expand...
Click to collapse
That's what i mean
Sources for patchs3k please
Sent from my Desire HD using Tapatalk 2

About the sources - I will create the article these days but I believe it doesn't matter; if you already have control over the custom kernel then you can just make it accept everything and see how things behave.
The trouble with what exFat (which I could also investigate if I have time) is that the CRC checks are thorough and if ANY of the structs used by exFat are different that what the kernel is build with, then there could be big issues with corruption of data and so on. Only Samsung (or sheer luck) could solve this issue. But I did not investigate so these are just assumptions..
@AndreiLux
Then it means I was extremely tired thanks for the explanations with hotplug. I have disabled the download so people won't take it without reading below.
One other thing, the kernel (3.0) like all other kernels has the posibility to create high priority work queues - alloc_workqueue with WQ_HIGHPRI as flag. It means that the work queue that rises the frequency should have higher priority so you don't notice any lag for example.
What I don't like about pegasusq is that it doesn't appear to create high priority work queues. I did not study carefully, but a quick search on the cpufreq_pegasusq.c doesn't show the high priority flag. Maybe the phone one has it ?
They also keep a history of the CPU usage (probably used with hotplugging also).
So I believe the two factors above might contribute to the lag I notice when waking up the phone.
I did notice this weird fact with the cores of the CPU not turning on or off with smartass2 - or remain in the state that pegasusq left them. I was checking test results and it appear to behave normally and have all 4 cores ON during stress test. It was late in the night and I did not check that they are not also shut down.
Maybe I should work on a smartass3 since I can add hotplug logic to smartass - but it is tedious you have to use locks and so on - and I don't have much time.
I think I have more success here with just building ROMs and not digging deep since you just take what everybody does and put a small thanks in a corner then you get all the Thanks and donations.

viulian said:
So I believe the two factors above might contribute to the lag I notice when waking up the phone.
Click to expand...
Click to collapse
The wake up lag is irrelevant to priorities or anything, it's caused by a) if you are referring to the wake up delay then it is because of the kernel is waiting for the modem to wake up which takes an eternity. b) if you are referring to unresponsiveness at the lockscreen, it was due to something in the Wifi drivers.

@AndreiLux Ok cool the modem interaction worths an additional look then!
BUT I have good news!
cpufreq_smartass2.c will be able to have hotplugging! I did a test module that activates cores and shuts them down and there it works.
In few days I will release the smartass2 with hotplug support for stock kernel.
One thing I saw, the pegasusq does NOT have a high priority work queue to bring the frequency up meaning that other work queues could interfere and actually introduce delays. It also has a complex logic to decide when to bring another core back online and it brings them back one by one.
I would like to have feedback from the community on what should be the bringing up / down behavior for each core for the new smartass2 governor.
I am tempted that upon waking up, to actually bring back all 4 cores at once. It is easier for me, FASTER to be executed (instead of going through heaps of samples to decide if one more core is needed) and is also on the same track with the initial smartass concept, FAST AND QUICK or go slow.
The delicate thing is how to handle shutting down cores. I can make it go back to 1 core and if loaded then bring back all again.
What do you guys think ?
I like this new way in customizing phones design by the community, not by what the rom cooker / kernel builder decides and that's it.

I find it fine and dandy, but the most critical point is why you would want to port such a feature to smartass when you already have pegasus with much more optimal frequency scaling. Also the frequency of which the cores are being hotplugged is incredibly high with runqueue sample rate/times of 50 milliseconds and time of bringing up the cores of only a couple of microseconds, all several orders of magnitudes below usual frequency scaling latencies. We've ported it to the S2 with magnificent results and ditched interactive based governors a long time ago, there is no benefit to it. Exynos is relying on aggressive and optimal DVFS scaling for power efficiency and interactive governors do not suit that too well.
It means that the work queue that rises the frequency should have higher priority so you don't notice any lag for example.
Click to expand...
Click to collapse
This is fine in theory but does it hold up in practice? The S3 is already considered as the smoothest running device running Android or even the smoothest device bar the iPhone.
Not trying to critique your work but I think your approach into improving things here is a bit flawed and viewing it from an odd angle.

Excellent constructive feedback! Thank you,
Let me explain my point of view:
1. First, there are many users that do not feel comfortable putting a custom kernel on the phone. Personally, I do not trust custom kernels even if they come with source code. Theoretically is correct to have the open; but I save a lot of time customizing what I trust (Samsung's stock kernel) than checking all the patches of custom kernels to start trusting them. And is not about privacy and so on, but I need the phone to work and I can't really tell if the custom kernel won't decide to play tricks when I mostly need it to work. So I stick with defaults and try to customize here and there.
2. Second, I have no idea how pegasusq compares with smartass2 unless I see them running - also, since I do debugging and so on, the phone uses different frequencies (mostly plugged and running stuff) and so I can't say if pegasusq matches the time_in_state pattern that smartass2 shows. Too early to tell.
And if it can be done why not ? It gives me more experience, it gives people alternatives. Plus, S3 is better than 4s, for sure, but what about the next phones appearing in the next half of year ?
This is just warm up for me to the phone, I have other ideas to dig and hopefully something will come up out of them (at least until the new big market killer comes around and we all jump ship to that one )

Any progress on this

None as it doesn't support multicore correctly...
Sent from my GT-I9300 using xda app-developers app

That was what he was trying to accomplish.andreilux and Simone gave him some new pointers.that's why I ask.

I had no time to take care of it but I am curious to do at least a bare metal version that will wake up with all 4 core at once instead of one by one which I believe pegasus does.
With the default one, the phone is sluggish for half a second when unlocking - I can see it because the launcher struggles for a bit.
But is true, smartass doesn't support cores activation/deactivation.

[FIX] Music Playback Crackling/Clicking Issue

First of all, id like to thank Gokhanmoral and Simone for the support... Special mention to TotallydubbedHD and Studiominal for the great contribution and to all who tested and helped...
The idea was first toasted by Gokhanmoral via PM, that it has something to do with idle status and not with hot-plug issue. Then Simone201 also posted about this on "official sound quality thread" which leads me to test dif configurations and combos... Then i came up with this little Fix:
1. You have to be rooted of course...
2. Flash Siyah Kernel (Sorry for this, since i only tested it with Siyah 1.3.3b and 1.3.7b)
3. Download & Install exTweak by Darek.Xan from the Playstore (Free one will do)
4. Grant Superuser
5. Navigate through the CPU Tab and set the CPU idle mode to; IDLE ONLY
6. Reboot
It was first tested with Siyah kernel 1.3.3b and was confirmed by Studiominal thru his "sinewave" that there were no crackling found in the graph. It has also been confirmed that it also work with 1.3.7b... I cant comment on other kernel since the test was thoroughly done with Siyah...
Hope this help... ENJOY!!!
For more info and progress about this finding, please read thru the thread
http://forum.xda-developers.com/showthread.php?t=1633685&page=75

{
"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"
}
Evidence provided
It seems like something in IDLE + LPA, AFTR + LPA, AFTR only causes the audio codec to suffer from power shortage that leads to turning the codec on and off really fast.
And.. to clarify, I only changed the cpu idle mode to IDLE ONLY, and disabled all the audio options that come pre-enabled both to see whether the idle mode is the culprit and wait for the new Voodoo Sound.

Thanks for the graph Pal...

Thanks guys for sticking with this and finding the problem.

Now that the culprit has become more obvious(likely the DAC being not able to perform properly with that low current set by stock setting), we'll see more developers here digging down the kernel with power profiles

Changed the setting to see what the impact on battery life is, i am not sure what lpe and aftr does, so not sure what effect we will see. Probably someone with more insight could clear this up...
–—–—–—–—–—–—–—–—
tapatalked from Galaxy SIII

So far, its been good with mine... Good deepsleep... When playing music, stayed on 200Mhz according to CPUspy..

jaytana said:
Then i came up with this little Fix:
Click to expand...
Click to collapse
Russians found this fix in June)
http://translate.google.ru/translat...howtopic=343482&st=2140#entry13910007&act=url

Hope its been posted here earlier to save our time and effort testing every bit of it...

jaytana said:
Hope its been posted here earlier to save our time and effort testing every bit of it...
Click to expand...
Click to collapse
but this is not the solution, it is a crutch

more of a temporary fix...

Iv never come across this problem but I use player pro and have never tried using the stock player, also, I use it with the lock screen player on which keeps a partial wake lock, perhaps this is what stops me having the problem.
I know the phone is awake because my nfc works when screen is off and player is playing.
Sent from my GT-I9300 using Tapatalk 2

Does this only effect Siyah Kernel?
Cause if its across the board on all current kernel sources what would be the solution to any any other kernel besides Siyah and using exTweak? A Script?
Also, I get choppy audio on almost all games and the same clicks on other audio related apps, could this be the same issue? This behavior almost sounds like latency problems of a low default audio pre-buffer...

JF-GINO said:
Also, I get choppy audio on almost all games and the same clicks on other audio related apps, could this be the same issue? This behavior almost sounds like latency problems of a low default audio pre-buffer...
Click to expand...
Click to collapse
So do I! It comes and goes but it's frustrating
Sent from my GT-I9300 using xda app-developers app

Are u two overclocking your CPU probably? Please give more details on your system, noone can help u this way.
–—–—–—–—–—–—–—–—
tapatalked from Galaxy SIII

According to Andreilux
LPA causes the CPU to be clock-gated, meaning the clock to the CPU is cut-off. I imagine that when power resumes, or actually is cut, it either causes a drop or spike in the power supply which interferes with the DAC and amplifier. This is inherently a hardware problem; they could have prevented it if they had put adequate filters on the PMIC, or whatever is in-between them which causes the interference. LPA is idiotically power-efficient and turning it off can cause worse idle battery life, so turning it off it in my opinion not a very viable option. The only options to fix it are already available to everybody already through changing of the idle states. If there's something to be done on the DAC-level itself, I don't know. CPU noise is a pain in the ass and wide-spread (Think about on-board sound on computers) and sadly there's not much to do about it if it's badly designed.
Click to expand...
Click to collapse

thanks for this, finally i've found the solution

Hi, this FIX is featured on the Index of FIXES http://forum.xda-developers.com/showthread.php?t=1674286
Any observation please send me a PM

Thanks...

I have been using, CM9 20120708-NIGHTLY with Ninphetamin3-1.1.1-test + Awesome Beats v3 (just beats boost active). No Crackling/Clicking Issue while listening to music with Apollo player.
I dont OC nor UV.