Hello, last two days I thought about I/O performance of great Asus Transformer Prime.
It is actually PDA so it means that device is not in the real power off state so much.
It can be used for ANY kernel and ANY rom!
Works with ANY ASUS TRANSFORMER MODEL!!!!!!!!!!!!!!!!!!!!!
Sooo let's tweak it for better performance!
We will reduce write times to SSD drive, no more hangups, ARNs etc.
I am using it on my own prime for one day and I have no delays at all.
For this test I need huge amount of volunteers to tune numbers in the script.
This change is only for actual session
If you want to save it after reboot use SManager for script autorun.
Here is script, run like. su
So download script on sdcard to root of sdcard, unzip and run:
Code:
su
cd /sdcard/
sh tune.sh
It is safe and it will not harm your system or break OTA update
The worst scenario is softresetting your device after
hang up (but it should be ok).
PLEASE I NEED RESPONSES FROM YOU!!!!
+ Faster system
+ less hangups (none on my Prime)
+ You don't have to flash new kernel
+ It is for actual session only, after reboot you have to run script again
+ Better battery life!
+ Longer life for internal SSD drive!
- If you reset your prime you can loose some of your datas
- If your system hangs you can loose some of your datas
- It is for actual session only, after reboot you have to run script again
EDIT: :::::::::::::::::: Ok version 0.2 is out. ::::::::::::::::::
With previous values I had problem with gmail.
With little tweaking I have no issues now and there is ALMOST no drop of permormance compared to version 0.1.
Changelog:
Code:
changed value for dirty_ratio from 90 to 70
changed value for dirty_background_ratio from 70 to 50
If you haven't gmail issues you don't have to install version 0.2
Nvm it seems that gmail issue had nothing to do with these changes
EDIT: 25.6.2012
Tune script is included here:
http://forum.xda-developers.com/showpost.php?p=27862975&postcount=149
:::::::::::::::::: EDIT 2: 26.6.2012 New version out v0.3 ::::::::::::::::::
+ tweak for battery (audio is suspended earlier when it is not used
+ some tweaks to cfs scheduler should be more responsive
Let me know your experiences with this version!!
::::::::::::::::::8.7. 2012 NEW VERSION OUT! v0.4 ::::::::::::::::::
Some of ideas taken from here ! http://forum.xda-developers.com/showthread.php?t=1205259
Optimalized for Prime
+ Added three types of scripts
+ 1st script = tune.v0.4.sh.zip = safe optimalization = only safe tweaks which will speed up IO operations a little bit
+ 2nd script = tune.v0.4.drive.sh.zip = drive optimalization = same like 1st script + optimalizations for internal ssd drive
+ 3rd script = tune.v0.4.max.sh.zip = heavy performance mode = 1st + 2nd script + "old" checked by users tweaks with background ratio, swapiness etc. + io mount tweaks + kernel tweaks + internet tweaks = max. perform. (for best turn sio TOO!!)
+ Longer life for internal SSD drive! Because noatime,noadatetime = less writes
- Somebody reported battery drain, so these relative functions were removed
Please for correct testing remove ATP application and run this script with SManager or manually (if you won't uninstall ATP it will change values...) If you don't want to remove ATP you have to wait for new developer of ATP when he will add these version of scripts to ATP !!!!!!!!!
If you have some problems after this script PLEASE try to remove ATP first, it seems that on some devices it has problems with running this script.
ok i m running it right now.
what are the default values?
Sent from my Transformer Prime TF201 using Tapatalk 2
Sorry I dont remember. Reboot your prime and you will see defaults.
batoo said:
Hello, last two days I thought about I/O performance of great Asus Transformer Prime.
It is actually PDA so it means that device is not in the real power off state so much.
It can be used for ANY kernel and ANY rom!
Sooo let's tweak it for better performance!
We will reduce write times to SSD drive, no more hangups, ARNs etc.
I am using it on my own prime for one day and I have no delays at all.
For this test I need huge amount of volunteers to tune numbers in the script.
This change is only for actual session
If you want to save it after reboot use SManager for script autorun.
Here is script, run like. su
So download script on sdcard to root of sdcard, unzip and run:
Code:
su
cd /sdcard/
sh ratio.sh
It is safe and it will not harm your system or break OTA update
The worst scenario is softresetting your device after
hang up (but it should be ok).
PLEASE I NEED RESPONSES FROM YOU!!!!
+ Faster system
+ less hangups (none on my Prime)
+ You don't have to flash new kernel
+ It is for actual session only, after reboot you have to run script again
+ Better battery life!
- If you reset your prime you can loose some of your datas
- If your system hangs you can loose some of your datas
- It is for actual session only, after reboot you have to run script again
Click to expand...
Click to collapse
Tempie007 said:
ok i m running it right now.
what are the default values?
Sent from my Transformer Prime TF201 using Tapatalk 2
Click to expand...
Click to collapse
Hi, it will be interesting to see how this works. swappiness=0 will cause less swapping to disk (it will only happen when it needs to). Default for swappiness=60 in our Android and mainline Linux kernels. These settings here are aggressive in trying to reduce swap disk i/o, so it will be great to see if it succeeds and whether or not OOM errors occur when RAM is running short when using RAM hungry applications or doing extreme multi-tasking.
I have also been testing something at the vm level in the kernel that I found in the HTC OneX source. It is something the HTC engineers added that would actually set the default to swappiness=100, the complete other direction from what you are doing here. This theory is to clear out the stale RAM and open up the RAM for something more useful. While this may be counter-intuitive to I/O performance since swapping equates to more disk i/o, the code change also implements some changes to the block, fs, and mm portions of the kernel. Essentially, from what I can tell, it flags and handles disk operations (aka "bios") differently if they are involved in swap operations (going to or coming from swap). A "bio" is essentially a manifest of an ongoing I/O block device operation, what sectors and memory locations it contains etc. Once the RAM is freed up, I have also been increasing the Dalvik vm settings in the build.prop to allow for more RAM consumption. So far, this combination (at least for me so far) has really given me good UI performance and I haven't had to kill the browser often like I did before. I have yet to play with vm.dirty_ratio and vm.dirty_background_ratio, but I am wanting to do this as well to see what combination can work the best for us.
Anyhow, thought I would share. I think you are looking at some important things here with the tuning of virtual memory to see how they can affect disk performance and more importantly application fluidity.
Cheers
Hi
I'm using it for about two hours and I had one reboot when I opened File explorer (before this never happend to me on .28) Im using also IO Sio from Your other topic (it seems to be alright...everything seems to work smoother). On tune.sh I have better write to sd speed in antutu. Now I have 8 mb...before 2 mb. Thx for that.
_motley said:
Hi, it will be interesting to see how this works. swappiness=0 will cause less swapping to disk (it will only happen when it needs to). Default for swappiness=60 in our Android and mainline Linux kernels. These settings here are aggressive in trying to reduce swap disk i/o, so it will be great to see if it succeeds and whether or not OOM errors occur when RAM is running short when using RAM hungry applications or doing extreme multi-tasking.
I have also been testing something at the vm level in the kernel that I found in the HTC OneX source. It is something the HTC engineers added that would actually set the default to swappiness=100, the complete other direction from what you are doing here. This theory is to clear out the stale RAM and open up the RAM for something more useful. While this may be counter-intuitive to I/O performance since swapping equates to more disk i/o, the code change also implements some changes to the block, fs, and mm portions of the kernel. Essentially, from what I can tell, it flags and handles disk operations (aka "bios") differently if they are involved in swap operations (going to or coming from swap). A "bio" is essentially a manifest of an ongoing I/O block device operation, what sectors and memory locations it contains etc. Once the RAM is freed up, I have also been increasing the Dalvik vm settings in the build.prop to allow for more RAM consumption. So far, this combination (at least for me so far) has really given me good UI performance and I haven't had to kill the browser often like I did before. I have yet to play with vm.dirty_ratio and vm.dirty_background_ratio, but I am wanting to do this as well to see what combination can work the best for us.
Anyhow, thought I would share. I think you are looking at some important things here with the tuning of virtual memory to see how they can affect disk performance and more importantly application fluidity.
Cheers
Click to expand...
Click to collapse
Ice increased my dalvik vm also through build.prop. Like the heapsize, growth limit, startsize etc...how much can you increase those vm to where its still safe? On stock kernel.
What values are you running at? IM also using that dalvik jit mod.
demandarin said:
Ice increased my dalvik vm also through build.prop. Like the heapsize, growth limit, startsize etc...how much can you increase those vm to where its still safe? On stock kernel.
What values are you running at? IM also using that dalvik jit mod.
Click to expand...
Click to collapse
Not sure how much room there is since I have only tweaked on the prime recently. I am running 8m, 64m, and 256m now. One of my other tabs used higher dalvik settings like this on the HC stock ROM (GT 8.9 or Iconia A500 can't remember). There are so many parameters to take into account for any given test etc., as they say "you never step into the same river twice" LOL.
I have posted my latest alpha kernel with the aforementioned changes. It will be interesting to see if folks like it or not. It is working great for me thus far.
Guys pls no offtopic and chat.
Ill try this new tweak once I get off work.
my first problem. cmclient has stopped.
first time I have seen this in weeks and it comes after 45 min of this tweak.
However it may be related to the fact that I have not used the default browser in weeks.
whycali said:
my first problem. cmclient has stopped.
first time I have seen this in weeks and it comes after 45 min of this tweak.
However it may be related to the fact that I have not used the default browser in weeks.
Click to expand...
Click to collapse
a reboot should clear it. did you enter in commands exactly like listed in op? it tells me file not found. when i unzipped the file, it gives me a tune.sh txt file or whatever. in the commands, is it supposed to be "tune.sh" instead of "ratio.sh"? i see i can just click the file and execute the file like that, bypassing the need to enter in commands. same like with overclock files. i could just execute them manually instead of using an overclock app.
have you noticed any other issues? what benefits have you noticed so far? you have me hesistant to execute the file now, since those commands give me error.
demandarin said:
a reboot should clear it. did you enter in commands exactly like listed in op? it tells me file not found. when i unzipped the file, it gives me a tune.sh txt file or whatever. in the commands, is it supposed to be "tune.sh" instead of "ratio.sh"? i see i can just click the file and execute the file like that, bypassing the need to enter in commands. same like with overclock files. i could just execute them manually instead of using an overclock app.
have you noticed any other issues? what benefits have you noticed so far? you have me hesistant to execute the file now, since those commands give me error.
Click to expand...
Click to collapse
PM'd you. it was just an alert. no need for reboot. hard to see or report anything yet.
whycali said:
PM'd you. it was just an alert. no need for reboot. hard to see or report anything yet.
Click to expand...
Click to collapse
Did you guys get this to work, I keep getting the file not found message
whycali said:
PM'd you. it was just an alert. no need for reboot. hard to see or report anything yet.
Click to expand...
Click to collapse
MRCANNADY said:
Did you guys get this to work, I keep getting the file not found message
Click to expand...
Click to collapse
If you want to try the OP's settings, you can easily change these and other virtual memory related settings graphically using the free app System Tuner under "SysCtl". This may be easier for those that don't like messing around with scripts. You can also optionally have the settings to be activated on boot if you test them thoroughly and want them to persist.
I ran
sh tune.sh
as the third command since that was the file name. nothing to report beyond the first one I posted here. I have not sodded yet and have folded my prime closed for a while since implementation.
im getting great results so far. no lag during app store apps updating and installing. plus the apps download and install so fast now. I think this mod along with SIO scheduler, build.prop tweaks, and overclock makes the prime scream speed. no negative drawbacks running this so far. i havent tested playing games yet.
whycali is correct. the filename in the command needs to be changed to what he posted, tune.sh
I am so sorry I changed typo in firat post to tune.sh, my test version had diff. Name.
i am going to try this based on the awesome feedback i have read. i will be testing alongside Chainfire driver and CFQ using ATP Tweak. i will report back. i do have some dalvik tweaks that may yield extreme lag free by forcing zygote to recognize 4 cores along with JIT.
Sent from my Transformer Prime TF201 using xda premium
I don't think that tweaking over heap size and experimenting with JIT will help so much.
This is the cleariest way how to speed up system.
swapiness is useful mainly with swap location but prime doesn't use swap at all.
It's true that these values are agressively focused on smooth UI but it's the point.
I am working on another tweaks.
These things can be of course written to startup scripts to the system, but I don't want to unlock my Prime and when I don't have CWM I won't risk some mistyping resulting to bootloop.
This is the most effective way how to safely reach good performance.
Don't blame Asus that they didn't setup these values, they need to keep some "safe" standards.
Anyway I will try to explore more effective ways.
Guys let me knows your experiences!!
I already tested some heavy applications like Nova 3 and it's working without problems...
Results are in
With out Tune.sh script and SIO at balanced setting:
{
"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"
}
Same but at Performance Setting:
Now with Tune.sh and SIO enabled at balanced setting:
Same with Performance Setting:
You be the judge. Running .28 ASUS Stock and LOCKED bootloader
Sent from my Transformer Prime TF201 Biotchh
Related
Topics Covered in this Thread So Far (or "potential areas for investigation/improvement")
USB modes confusion, CD-ROM mounting bug, and how to make it useful
Hunting for buried treasure in system apk's
EFS backups
GPS
Wifi
Stuff About CDROM/USB Device Protocols
More Stuff About CDROM/USB Device Protocols
Stuff On EFS
Stuff On Hidden Options
GPS power toggle from Drop Down Menu
EVRC-B Phone Voice Codec
Background Noise Cancellation during call
Disabling of debugging stuff and additional code checking
PNG/ogg optimization and Zipaligning
libdvm.so Optimization
Battery Service Polling
RAM management
Disk Scheduler
A more complete nandroid solution
A better voodoo implementation
About scripting
Sleep of Death
Phone.apk mods
More EFS partition info
Info about other partition backups (backing up kernel and others)
Wakelocks/Timekeeping issues and fixing it at the kernel level
Partition mounting tweaks (noatime and such), power management, vm writeback time
More VM tweaks
SD card cache tweak
Reclaiming the Preinstall partition
So I'm going to be out of town for a week or so, and I know that with hacking, that means I could come back and nothing will have changed... or I could come back and everything will have changed (source, anyone?)
EDIT: I'm back... and everyone got thunderbolts! I swear, I leave for one week...
Unfortunately, I myself am a jack-of-all-trades (king of none, sadly), so I've got about 50 different little things I've been working on researching, and won't make much progress on if I keep on trying to do them all at once, since every single project requires that I learn an entirely new set of principles that I never knew about before. Because of this, I have decided to do a brain dump. Hopefully this is welcomed. Some of it will be stuff you already know, some will be dead leads that don't apply, but I hope that there are some nuggets of goodness that will inspire someone to investigate further.
Basically, I go hunting for things that catch my eye, and mark them to investigate later. Unfortunately, later on, I can't find it, so I have to find it again. Therefore, I'll try to present the most I can re-find about a given topic. Also, my memory is very shoddy, so beware of inaccuracies. I am not stating this as a gospel truth, but as a jump off point to maybe catch your interest to go investigate something further. I welcome any discussion, but if you take an idea and make it your own, feel free to start a new thread about it.
Part I:
USB modes confusion, CD-ROM mounting bug, and how to make it useful
Samsung integrates several different USB devices into that one little plug. I count the following:
1. UMS - Mass Storage Mode (looks like a jump drive)
2. MTP - For use with media players to transfer music/videos/pics (looks like a media player)
3. CDFS - Mounts an image onto a virtual device (looks like CD-ROM drive)
4. DUN - Used for Dial-up-networking (looks like a modem)
5. COM port - Used for programming using low level tools like QPST (looks like a serial port)
6. ADB bridge - communicate over adb to the phones through a terminal
With the possibility of TV-out over usb, USB On The Go, or USB Host, then there are probably more.
There is a lot of weirdities that happen because there are different parts of the phone that activates different "modes" which are usually a combination of the above. Try rebooting into CWM and then select to mount the USB. Depending on your set up, you will probably find your SD-drive mounted to the virtual CD-ROM device. Is it the kernel or recovery that's not set to the right usb mode? I don't know.
There are so many different areas that can change the USB device, so it can be confusing to know why you are seeing a certain thing, even though you have it set as something else from the menu. Just a few examples: In the Settings, you have Debugging, which will turn on UMS, CDFS and the ADB. Depending on what Settings.apk you use, there is an accessible Dial-up networking option to enable the modem. There are dialer codes that affect the enabled devices(**usbii which accesses the PhoneUtil.apk, **debug which allows you to change the port map, and toggle DUN). There is a persistent ADB property that can be stored in "/data/property/persist.service.adb.enable". There are system settings that can be added to the .prop files that load on boot, or set by "setprop somepropertyhere" using a terminal or script.
Have you ever plugged in your phone and gotten an autorun prompt that says something about verizon? On the stock roms, there is an ISO that is stored at "/system/etc/verizon_i500.iso". It contains the samsung usb drivers and a couple other things. When it works properly, this would let you install everything you need to get your phone connected to a new computer, without going through the hassle of finding the files. This is especially helpful if you only have internet access through your phone and cannot obtain the drivers elsewhere. All this seems to be handled by the kies service manager, which does really weird quirky things. For instance, you can manually mount the iso onto this virtual cd-rom device, but kies will unmount it after 15 seconds or so. This is why sometimes, if your sdcard gets mounted as a cd-rom, you can actually read the contents for a little while before it disappears.
Why does this matter to anyone? Well for one thing, it explains a lot of the bugs. There are so many different devices, that sometimes they get mixed up in scripts. This is especially true when porting from other software, or mixing and matching kernels and OS's and recoveries. If they aren't all in agreement, weird things will happen.
Secondly, it opens up a cool built in feature that could easily be utilized: emulated cd-rom drives! I haven't isolated the properties (but it doesn't seem too hard to figure out using the logs and such), but I have successfully mounted the memtest boot iso to the virtual CD-rom drive. Think about it: you have a 16gb sdcard in there. Throw on a live-linux iso, and if the computer was made in the last 5-10 years, it should be able to boot from it (not tested yet).
Right now, you can quickly verify this works by making a symlink from /system/etc/verizon_i500.iso to the iso on your sd card. Then, if you know how, enable the virtual cd-rom (I can't remember the exact variable but its as easy as "setprop cdfs.something enable"). There you go! Instant Virtual CD-ROM drive. You can use it to install stuff on your netbook that didn't come with one, or turn your local library PC into a hacking command center (that's a joke... don't do that).
Now obviously, this could be easily packaged up into a neat little apk that would enable the right USB mode, and then allow you to pick the ISO you want to mount. This would be the ultimate goal, not this dirty little demo. Even easier to implement would be to call it from a script, using a script shortcut program.
Part II
Hunting for buried treasure
There are a lot of things hidden in the OS. Almost all of the APK's, if decompiled, have things that are hidden. Sometimes, the full code is there, but the ability to access it has been removed. To make it visible, you may only need to add the info to the layout xml, or remove a line of smali code (look for things like "removePreference" and such).
Other times, it's just a stub of the information. The great thing is, there are so many variations of our phone, almost anything missing can be inserted again if you can find it another device's code. Sometimes, this is a huge pain, because the dependencies can be spread over multiple files, requiring quite a bit of persistence and dedication. Other times, it's as simple as copy and pasting a line, or an entire method.
The i9000, Mesmerize, Captivate and Vibrant seem to have lots of our missing goodies, but a lot of them need to have the code adjusted, and I don't know what to work on first, since some of the easy stuff is worthless, and some of the valuable stuff is impossible. Here are just a few of the screen shots I've taken (yes, I realize a lot of them are probably not portable, but just showing you how much stuff can be hidden in an APK):
http://www.dropbox.com/gallery/22143517/1/Settings?h=7cc415
There are a lot of little APK's that can only be accessed by dialer codes or through a shortcut program. The useful features sometimes are very small and could either be hacked into the main Settings.apk, or called from it, or added into SpareParts.apk. There are a lot of dangerous things in there ("You want me to format your phone and your SD card?" "Nnnn-" "FORMATTIN YO SDCARD YEAAAAAY") so be careful exploring.
Which brings me to another big issue: EFS backups.
One night, before going to bed, I was poking around in a hidden menu (yep). I don't remember actually changing anything, but I lost a setting. Of course, I have no idea what the correct settings are, so I didn't know what to look for, and for 12 hours straight, my data connection would connect and disconnect every minute. I learned a lot about how poorly the os/radio/kernel/something handles the data connection, but I also learned about the EFS partition, and how this could have easily been fixed if I had a backup, and also how it could have been much, much worse.
If you wander through the i9000 forums, there are multiple warnings to backup your efs folder before messing with any settings. If you corrupt certain files, your phone will lose the ability to regenerate its EFS data, and you will lose your IMEI number. Meaning, your phone will not be activate-able. Meaning, your phone will have to be shipped to Samsung to get it fixed, so... good luck with that. If you think you are smart enough to avoid this, if I remember right, supercurio lost a device to this while trying to figure out the secret audio settings stuff.
It's simple to backup the entire partition using your favorite terminal command (I used dd to copy the efs dev/block device to the sdcard, don't know if this is the best method or not). However, it is virtually impossible to get it back once it is gone, if you don't have a backup. (There is someone charging for this service for i9000 phones).
My theory is that i9000's being used on different carriers causes lots of more people to play around with the EFS data, causing more people to corrupt it. Since the Fascinate is mostly only getting used on Verizon, then there aren't as many cases. However, one mistake in a mounting script in a recovery/kernel/os, and you're toast. Not only that, if you have a working backup and you go messing with the radio settings, then you will always have a backup that doesn't require you to activate another phone and then reactivate your's in order to get your phone working again. (All the while, watching in horror as your logcat fills with a continuous stream of data connection failures).
This is something I'd love to hear more from by someone who knows about it, and if it's as valid of a concern as it is on the i9000, then I'd really like to see more publicity about it's importance.
Part III
Is supposed to be about GPS and wifi, but dang, that is a crazy amount of stuff to write. I hope that a little bit of info, along with a link dump will be okay. And to be honest, I'm getting tired of typing now. I keep thinking of more stuff, but I haven't even fully fleshed out what I've posted so far. Hopefully, I'll be able to do some more later (and even more hopefully, there comes some good from it).
GPS
Most promising is the Captivate GPS work. This thread is a little bit old, but it contains good info. There might be newer information available as well:
http://forum.xda-developers.com/showthread.php?t=881941
The i9000 GPS dev has some good posts as well, explaining it very well. Again, there might be newer information, but this is what I have bookmarked:
http://forum.xda-developers.com/showthread.php?t=842694
It talks about using the "LbsTestMode.apk" for testing. I have no idea if it works for actually configuring the files (I was told it doesn't), but I am providing it here for the possible testing it can do:
LbsTestMode.apk
http://dl.dropbox.com/u/22143517/Android/LbsTestMode.apk
This is just a quick (and not very entertaining) video of setting up a shortcut to access it instead of using a dialer code, then running through the menus real quick so you can see what is available.
http://dl.dropbox.com/u/22143517/Android/lbstestmodedemo.mp4
From a cold boot, in google maps, I can get a lock down to 2 meters in 3-5 seconds with wifi off and GPS standalone enabled when I'm outside. Inside, usually 10-20 meters at first, then drops to 5 after a few more seconds. So I don't know if it's something I've done, or if I just got lucky with a good chip, but I have a hard time testing GPS fixes because I don't have problems (but things can always be better, right?)
I highly recommend checking into the app "GPS aids" if you like the idea of assisted gps. I find that AGPS hinders my GPS performance, but after using GPS aids, it's about as good as normal. So for someone with bad standalone GPS performance, maybe it would help them out using AGPS.
Wifi
Oh boy... I don't know where to start with this. It completely ignores the system property wifi.supplicant_scan_interval. There are files spread across /system and /data that relate to wifi. The binary 'wpa_supplicant' is a source of hackery on other systems, but I don't know if anyone has attacked it on the Fascinate side of things. Want to see ad-hoc networks? This is the file that they usually hack to do that. Other devices have hacked the ability to enable infrastructure mode for wifi tethering. I don't know if this has been done yet for SF.
There are a lot of hidden wifi, wps, and tethering options in the Settings menu. Several system settings properties relating to wifi, several .conf files for the messing, wlan services for the playing, and a nice engineering mode when calling WlanTest.apk that says it's loading a different driver (I can't remember what all neat stuff is in that).
Stuff About CDROM/USB Device Protocols:
My thoughts exactly, the cdrom driver is useful, maybe more so.
The issue as to what starts when is configurable, Eclair had a hard limit of 2 usb modes at any given time, if I recall correctly Froyo supports 4 and that maybe a hard limit by the device. So what is running has to be carefully chosen, with mtp, virtcd, virtcom, ums, adb, acm, usb-otg, tvout, wired tether you hit 4 quick. This is an issue on my table but of low prority, as without a fully working kernel these amenities become mute.
I intend to make the cdrom driver configurable to select various isos from sd and switchable on command, I feel it would be more useful in that state, and I plan to give the user more control over what usb modes are selected using a sysfs setup, the defaults are in about 6 profiles that barely cover my needs without slowing me down.
Edit, More Stuff About CDROM/USB Device Protocols:
I have never tried to get all of the devices working simultaneously, but I do know that if you enable the virtual com port for EFS editing that DUN support is disabled, and that if you enable UMS(USB MassStorage)/SDcard that UMS/VirtCD is disabled, and if you enable UMS/VirtCD that UMS/SDcard is disabled, and I don't use MTP (think syncing your music from WindowsMediaPlayer to Android) so I'm not 100% sure about this one, but I think MTP is disabled if ADB is enabled. At least this is how stock is anyway.
Stuff On EFS:
The I9000 EFS stuff is a little out of my department, but I would love the ability to edit EFS reliably within the OS, unfortunately unlike with the I9000 our devices do not mount an EFS partition, and I have not ventured to attempt looking for it. I imagine it would be just as easy for us to edit it in device as it is for the I9000 people, however if it is due to the way the radios are handled this may not happen, as we are still trying to figure out where the Fascinate keeps it's modem, it would make sense that the EFS partition and the modem code would rest in the same area or partition, if we could only for certain identify it. I think the FSR and FSR_STL drivers obscure our view of it, no fear, I will be attempting to import Gingerbreads MTD work into the my WIP Froyo to hopefully solve this issue once I get the radio working reliably. If and once we do have access to EFS, we could technically copy and replace or edit our Verizon EFS information live, flash from one network to another, and update tower information possibly without even restarting the phone....that is IF we have access to the EFS partition, and logic says we should have access to it ( as every other CDMA Verizon and Alltel device I have used does have one ) and it is programmable from within the Samsung device setup APKs.
Stuff On Hidden Options:
As for the special hidden stuff....it just boggles my mind the amount of crap they hide (or did they forget about this stuff?!?) from us, most of it doesn't work, most of it has no warnings for the DANGEROUS stuff it can do without prompting for a confirmation (ie complete factory reset and yes sdcard formatting) I think this crap should have been jammed into a single engineering menu accessible via a fixed passcode rather than scattered from A to Z in 20 different APKs with little more indicator of what an option does than some cryptic function name and a report of what someone else may have experienced only after executing the command. At the very best it's an unorganized, inefficient, undocumented, unreliable, low level, factory device configuration menu set that even most experts do not know how to fully utilize.
SirGatez said:
My thoughts exactly, the cdrom driver is useful, maybe more so.
The issue as to what starts when is configurable, Eclair had a hard limit of 2 usb modes at any given time, if I recall correctly Froyo supports 4 and that maybe a hard limit by the device. So what is running has to be carefully chosen, with mtp, virtcd, virtcom, ums, adb, acm, usb-otg, tvout, wired tether you hit 4 quick. This is an issue on my table but of low prority, as without a fully working kernel these amenities become mute.
I intend to make the cdrom driver configurable to select various isos from sd and switchable on command, I feel it would be more useful in that state, and I plan to give the user more control over what usb modes are selected using a sysfs setup, the defaults are in about 6 profiles that barely cover my needs without slowing me down.
Click to expand...
Click to collapse
Glad to see you in here, as I think the whole issue is very much best implemented/fixed from the kernel with the OS just facilitating from there. Also interesting that someone else was thinking about this while I was. With the little amount of knowledge I have, trying to hack around the different usb profiles at the OS layer is a pain. ("let me mount this" "NO, STOP IT!" "come onnnn let me turn that on")
I know I personally have had UMS, CDFS, DUN, Serial, and ADB all showing up in windows device manager at the same time, by manually toggling them on. That was as far as my test went, so I have no idea if they were accessible at the same time. But it's interesting to watch the device ids change as it switches modes. I have very little driver knowledge, so actually doing much digging was over my head.
Ok, I think I'm done for the night. Sorry for the quality of info, I'll try to work on it more sometime soon.
I feel like we are all just holding our breath for froyo source, but a lot of profitable work can be done in the meantime. Really, a lot has already been done that we can just kang from other devices. We just need to look outward at our foreign cousins.
For instance, supercurio did a lot of work on hacking the sound before they had kernel access. Using his methods from back then might give us some improvements in the meantime.
Things like GPS and Wifi will probably continue to be an issue even after we have source, so they can be done without fear of being completely forgotten about as soon as source drops.
Lots of mods and tweaks that are widespread across other devices don't seem to be discussed. Build.prop hacks are cheap and easy things that don't get much action around here (though not all of them are applicable/or even helpful). Someone brought up the FuguTweaks thing the other day from the Captivate forum. More of these cross-device discussions would be awesome.
God, my brain just exploded.
This is actually quite interesting, though. Now, on Part II: certain Sammy .apk's have hidden usage? Could we combine that into a massive super-settings app?
Samsung Fascinate, Verizon
EB01 Superclean 2.4
Kenesis' TransMyst GBKB (EPIIIIIC)
Mob87's Honeycomb Theme
Stock Kernel
obsidianchao said:
God, my brain just exploded.
This is actually quite interesting, though. Now, on Part II: certain Sammy .apk's have hidden usage? Could we combine that into a massive super-settings app?
Click to expand...
Click to collapse
That's the idea. CM has a lot of this kind of thing, but we aren't there yet. There are also a bunch of testing apks that I didn't mention built right into the stock ROM.
There are even some super mega apps (some available on the market) that are somewhat compatible (be careful with these, especially for low level stuff). "Sysinfo" reveals a lot of... system info that you normally have to go digging around for. So does "Under the Hood". "Tuxility" doesn't really have much, but could be an easy start for the basis of a SF compatible utility. "SuperPower" gives a lot of control over power options. "SpareParts" from other Galaxy variants have had lots of options added. There are some other SGS specific tools that half work, as well, but their names are slipping me now. One allows you to flash a kernel from the OS. Also, I wonder if Development.apk from the emulator might have some use?
There are tons of things that could easily be added to the SpareParts app too, if you didn't want to add it to the Settings app.
So much stuff to kang.... so little time.
Dude. This is... amazing. Can you mentor me on this stuff? XD
Now, Spare Parts is that app in SC that shows the battery info and stuff, no?
Edit: and what all could you drag to spare parts? Could it access those hidden .apk's and utilize the secret functions?
This is so cool.
Samsung Fascinate, Verizon
EB01 Superclean 2.4
Kenesis' TransMyst GBKB (EPIIIIIC)
Mob87's Honeycomb Theme
Stock Kernel
Part 4
GPS power toggle from Drop Down Menu
The GPS option from the drop down menu is essentially broken and needs to be fixed. I recall a similar problem on a different device with the wifi. With that device, on observation, I noted that on powering up wifi from the settings menu, I would be connected within 5 seconds, but from the power widget, it would take a full minute. After doing some investigating, the power widget was basically trying to control the wifi device directly. I found a different widget that essentially emulated the same method used in the system settings menu, and it starting connecting immediately. My guess is that the GPS power code on the pull down menu could be modified using the same examination/modification needs to be adapted in the same way.
EVRC-B Phone Voice Codec
Switching to the EVRC-B codec improves call quality substantially, for both parties of the call. If anyone knows of a way to set it that doesn't involve going into service mode and manually changing it, then please let me know.
Background Noise Cancellation during call
Also, I'd love to find a fix for the mic during calling. It's a frequent occurrence for the person I'm calling to be like "Who are you talking to?" because they hear someone talking in the next room away from me. Or a very light sound on my end, elicits a response of "WHAT IS THAT NOOOISSSE??!" from the person I'm talking to. So obviously an issue of background noise cancellation. I'm hoping its a software fixable problem.
I've seen this build.prop edit to mess with the noise cancellation for disabling noise reduction for the voice recorder (Say you are trying to record something like music, or something at a concert, the noise filter would hinder your ability).
Code:
media.a1026.nsForVoiceRec=0
media.a1026.enableA1026=1
Two things about this:
1. I've only seen this kind of property on other devices that have two mics that work in combination for noise cancellation. I'm guessing the SF only has one, and any attempted noise cancellation is done at the hardware level or in software.
2. This would assume that the noise shield actually exists, but the stock Fascinate behavior is to not have it enabled for calling... which is pretty dumb. Given some of their other decisions, this may be true, but I have my doubts. If it's parameters are accessible, and it's merely only needing some tweaking, then I will be happy.
I wonder if supercurio knows much about the noise cancellation, since he's worked with so much of the sound stuff?
Disabling of debugging stuff and additional code checking
Debugging stuff is essential for figuring out problems, but for the 99% of the time, isn't it probably slowing us down? I don't know what would be the best way to easily disable any additional debugging routines that might be affect performance.
As for disabling code checking, I used to run these build.prop edits on an older device. I have no idea if they still apply:
Code:
ro.kernel.android.checkjni=0
dalvik.vm.checkjni=0
dalvik.vm.verify-bytecode=false
Maybe you are the kind of person that needs their phone fully stable at all times (no you're not, because you are on a forum that is made to push your device to the limits). I, however, keep everything backed up, so if disabling this extra "security" might slightly increase risk of data loss, then I'm okay with that (not saying that this is an actual danger, but just in general). The only problem I have is if the increase is negated by a large rise in errors that actually hinder performance, or if it becomes significantly more risky (doubt that's the case, but it's always a possibility).
Somewhat related, we currently keep the dalvik heapsize at 48mb's. Is this the best match for our device, or just the default?
PNG/ogg optimization and Zipaligning
I recently took a superclean rom, and dropped 16MB losslessly just from throwing the pngs through PNGOUTWIN and deflopt (didn't touch the *.9.png files). Free RAM right there. Not to mention that some of those APK's have ridiculous extra resources that can be reduced by cutting color depth or taken out entirely (giant HTML based tutorial files stored in the apk... why?) Also, all of the ogg files can be slammed down using a sox script or an equivalent.
In compression, it's also important to know when its a free and harmless, or when it will reduce stability. You can zip up an APK nice and tight... but aapt is a better method. The files might be bigger, but they will run better (also, learn how to treat *.9.png files, or don't touch them at all).
I've adapted the script from Bugless pete's automatic, on-phone zipaligning utility (just had to change a couple lines). A lot of times there are apk's that slip through the cracks in the ROM's that aren't zipaligned (especially in themes and patches). Again, just free performance that isn't hard to obtain.
libdvm.so Optimization
Has our libdvm.so been optimized to run on on our processor? I know this was a huge boon for older devices, but couldn't find any info on ours.
Battery Service Polling
Ever watched the logcat even when your device is nearly at idle? Ya... that battery is always updating. How do we change this habit? I often wonder how much extra juice would we gain by increasing the length in between battery polls.
GizmoDroid said:
Ok, I think I'm done for the night. Sorry for the quality of info, I'll try to work on it more sometime soon.
I feel like we are all just holding our breath for froyo source, but a lot of profitable work can be done in the meantime. Really, a lot has already been done that we can just kang from other devices. We just need to look outward at our foreign cousins.
For instance, supercurio did a lot of work on hacking the sound before they had kernel access. Using his methods from back then might give us some improvements in the meantime.
Things like GPS and Wifi will probably continue to be an issue even after we have source, so they can be done without fear of being completely forgotten about as soon as source drops.
Lots of mods and tweaks that are widespread across other devices don't seem to be discussed. Build.prop hacks are cheap and easy things that don't get much action around here (though not all of them are applicable/or even helpful). Someone brought up the FuguTweaks thing the other day from the Captivate forum. More of these cross-device discussions would be awesome.
Click to expand...
Click to collapse
Your gonna hold your breath a long time if you're waiting for froyo source.
If anyone needed proof that Quadrant scores aren't good indicators of real performance, this is a real, unedited screen shot from my phone running EB01:
{
"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"
}
I dropped the link in IRC for giggles and a couple of people lost their minds, accusing me of lying. Sorry fellahs, I got better things to do.
You can boost your quadrant scores this high with a couple easy steps that provide absolutely no performance boost outside of quadrant (it's is similar to why voodoo enabled systems score so high, but only perform somewhat better). So for the hold-outs that still think that quadrant is a reliable benchmark... be aware of it's major flaw.
GizmoDroid said:
If anyone needed proof that Quadrant scores aren't good indicators of real performance, this is a real, unedited screen shot from my phone running EB01:
I dropped the link in IRC for giggles and a couple of people lost their minds, accusing me of lying. Sorry fellahs, I got better things to do.
You can boost your quadrant scores this high with a couple easy steps that provide absolutely no performance boost outside of quadrant (it's is similar to why voodoo enabled systems score so high, but only perform somewhat better). So for the hold-outs that still think that quadrant is a reliable benchmark... be aware of it's major flaw.
Click to expand...
Click to collapse
I have been trying to convince people of this flawed benchmark app for months when using Blazed Eclair, it scores almost normal but runs the same voodoo other kernels do plus lots of other tweaks on kernel side. Very few believed me and switched from Blazed JUST for higher quadrant benchmark scores
Sent from my SCH-I500 using Tapatalk
SirGatez said:
I have been trying to convince people of this flawed benchmark app for months when using Blazed Eclair, it scores almost normal but runs the same voodoo other kernels do plus lots of other tweaks on kernel side. Very few believed me and switched from Blazed JUST for higher quadrant benchmark scores
Click to expand...
Click to collapse
Maybe I should make a HOWTO tutorial on how to get ridiculously high quadrant scores on any OS/kernel, then people would be free from using it to influence their thinking and instead would base it on real world results.
The cynical side of me says that they would just find a new benchmark and do the same thing with it.
Meh, we know the truths, so sure make a howto, maybe quadrant will fix their flaws (yeah...i'm not sure about that one...) people on the otherhand will flock like you say without our intervention, but for the rest of us this could prove helpful in building roms/kernels that do not allow benchmarks to succumb to the same flaws that most current ones do
Sent from my SCH-I500 using Tapatalk
SirGatez said:
Meh, we know the truths, so sure make a howto
Click to expand...
Click to collapse
[HowTo] Release the most downloaded ROM of all time:
Take stock rom.
Insert the following line into a boot script:
Code:
mount -o rw -t tmpfs tmpfs /data/data/com.aurorasoftworks.quadrant.ui.standard
Upload ROM to host of your choice.
Post screenshots of Quadrant scores with download link.
Great Success.
There are lots of ways to inflate quadrant scores... but this is the funniest method because it makes it ridiculously obvious how voodoo can achieve inflated quadrant scores without gaining a similar amount of performance (they both write cache to memory, therefore inflating the I/O scores ridiculously high).
Adding more to the noise cancellation issue, I found some more info out tonight:
Jamezelle pointed out a property that is set in res/values/bool.xml in the Phone.apk "has_noise_suppression" and it's set to false. After digging around, I found that this shows up in the PhoneUtils class if you decompile Phone.apk. It reveals two options: "noise_suppression=auto" and "noise_suppression=off". Some realworld testing needs to be done, but if the fascinate has the noise surpression ability and its just turned off, then this could be turned on again by adding to build.prop, or by modding the options menu to have this show up as an option.
Its very possible that it's hidden because it's not implemented, but other Galaxy S phones have some type of noise cancellation, so it might just not be implemented in the software.
Don't know if you were still looking for how to change EVRC to EVRC-B, but dial **72, the spc code is 000000, press down on the directional button arrow until you see Svc mode nam 1 end of basic nam exit. Press the right directional key once, you will see EXIT change to more, hit enter, press down once and you will see HomePage VoiceSO and EVRC, push the right button to change to EVRC-B. Hit ok and phone will reboot. Sorry for the sloppiness, at work and trying to be quick.
Edit: Ah, nevermind, you didn't want service mode, sorry!
Sent from my SCH-I500 using XDA Premium App
Dread This Day said:
Don't know if you were still looking for how to change EVRC to EVRC-B, but dial **72, the spc code is 000000, press down on the directional button arrow until you see Svc mode nam 1 end of basic nam exit. Press the right directional key once, you will see EXIT change to more, hit enter, press down once and you will see HomePage VoiceSO and EVRC, push the right button to change to EVRC-B. Hit ok and phone will reboot. Sorry for the sloppiness, at work and trying to be quick.
Edit: Ah, nevermind, you didn't want service mode, sorry!
Sent from my SCH-I500 using XDA Premium App
Click to expand...
Click to collapse
Yeah, this way does work, and I have used it multiple times. But it resets itself every time you reactivate, and its near dangerous settings, so its not something I would recommend to newbies.
If there was a less dangerous way to set it (say from a script or an apk) then this could lead to it being more widely recommended. It really does provide substantial improvement of call quality.
If my gf calls using her bluetooth headset, which has mediocre sound quality, the further compression of EVRC makes her very hard to understand. With EVRC-B, I can understand her plain as day.
Dread This Day said:
Don't know if you were still looking for how to change EVRC to EVRC-B, but dial **72, the spc code is 000000, press down on the directional button arrow until you see Svc mode nam 1 end of basic nam exit. Press the right directional key once, you will see EXIT change to more, hit enter, press down once and you will see HomePage VoiceSO and EVRC, push the right button to change to EVRC-B. Hit ok and phone will reboot. Sorry for the sloppiness, at work and trying to be quick.
Edit: Ah, nevermind, you didn't want service mode, sorry!
Sent from my SCH-I500 using XDA Premium App
Click to expand...
Click to collapse
Thanks, working great! But you posted incorrect dial code. Let me correct you. **772
Based on this thread:
http://forum.xda-developers.com/showthread.php?t=1595531
and this one:
http://forum.xda-developers.com/showthread.php?t=903507
After quite some reading and messing about it worked...
I have patched sqlite3.c from CM9 ICS source and recompiled CM9 (for nexus, the tutorial used that one... but files seem interchangable).
!!!WARNING!!!
!!!Use this at your own risk! I will not be responsible for any messed up primes, errors and/or loss of data!!!
This can mess up your prime! Only do this if you have a working CWM backup and can restore that backup from recovery! Root is required at this time to replace the files...
I have no idea what this does with data integrity, if you value your data extremely it might be wise not to try this!
!!!WARNING!!!
*RISK*
As explained by Hobbesian in this post: http://forum.xda-developers.com/showpost.php?p=27121811&postcount=39
Fsync off means that SQLite is unbound by the need to check that data has been written to disk successfully, it also means the operating system can freely re-order the writes before they are comitted to flash memory, which in the event of a hardlock will very likely result in database corruption, of the unrecoverable sort.
Fsync in itself is often used -deliberately- to incur an I/O buffer, so whilst it might seem like a great idea to turn it off, what you're essentially doing is risking the CPU going faster than the device controller can write to memory. This is bad. I cannot begin to imagine how many klaxons would go off if you're working on something remotely important and use this patch.
*RISK*
I hereby attach the zip containing the libsqlite.so and libsqlite_jni.so.
1. Copy the files (using root explorer for example) to the /system/lib folder, replacing the original files. (Mount that folder as RW if necessary).
2. Set permissions to the same as the other files, rw-r--r--.
3. Reboot.
If something went wrong your prime will not boot but will be stuck at the booting screen, in that case recover to a working backup using CWM.
SQLite benchmark went from 100+ secs to 20-25 seconds. Quadrant IO bench improved as well.
Have yet to decide on realtime performance but I actually believe the internal memory is pretty mediocre, physically... So this only helps partially in that case.
It's fun to play with sync settings but not if you value your data. I would strongly advise against it except for testing and benchmark purposes...
Thanks, but Iḿ awarre of possible consequences... But I believe the conclusion in earlier versions was that, even though there are indeed risks, they aren't as huge as you'd might expect. Mainly with unexpected reboots or shutting down the risk is big(ger).
But even if itś just for testing/benching... I would still very much like to see the results.
Btw, it should be ARM v7 even... that is the proper instruction set. Updated starting post.
Ugh, got it to build for arm-v7a but of course it looks (completely) different from the module with the prime. Structure the same, but compiled different enough. So thought I'd compule the library and install it on the prime but that resulted in the prime not booting...
Hmmm
I'd love to help, but I have zero knowledge in anything SQLite...
I wish you good luck!
I think everyone is hoping that the slow random write speeds are purely software related. And it makes sense that they are. The SQLite benchmarking thread is giving a lot of details on what is making our performance so sluggish, but not why.
Next step, compile complete CM9 source (hopefully including libsql src ) so I can use that as a base...
Copying the libsqlite.so and libsqlite-jni.so from an AOKP rom worked fine, so perhaps this is a (not the easiest) way to get things to work.
And ah well, otherwise I learnt how to compile a rom
xTRICKYxx said:
I'd love to help, but I have zero knowledge in anything SQLite...
I wish you good luck!
I think everyone is hoping that the slow random write speeds are purely software related. And it makes sense that they are. The SQLite benchmarking thread is giving a lot of details on what is making our performance so sluggish, but not why.
Click to expand...
Click to collapse
Same here, thanks for taking time out to tinker with our primes...........hmm, im not intirelly sure if i should refrase that???
GD LUCK
dagrim1 said:
Next step, compile complete CM9 source (hopefully including libsql src ) so I can use that as a base...
Copying the libsqlite.so and libsqlite-jni.so from an AOKP rom worked fine, so perhaps this is a (not the easiest) way to get things to work.
And ah well, otherwise I learnt how to compile a rom
Click to expand...
Click to collapse
Are you actually changing rom code to remove fsync?
hairdewx said:
Are you actually changing rom code to remove fsync?
Click to expand...
Click to collapse
Ehm, basically... Not rom code itself but one of the libraries in the rom (for which I hope the code is in there as well).
Background info:
http://forum.xda-developers.com/showthread.php?t=1000899
Android phones as the underlying database using sqlite3. sqlite3 writes efficiency is very low, because the sync feature turned on by default, and fsync() must be performed after each insertion, the resulting system efficiency is low, and the disk life is reduced.
I try to disable sync feature by default in exchange for greater IO performance and reduce disk consumption. While doing so may result in data integrity problems, but I still like to use it because most of the sqlite insert action can be completed within a few seconds, not too much to consider issues such as sudden power-down.
After modified, the time of insert 2000 records to sqlite3 db, from 1m11s reduce to 2s.
-----------------------------
With Android applications, the database operation is non-persistent, normal step in app is:
1.open db
2.do read/write
3.close db
with step3, the data in cache will be flush to disk. so user will not notice any sudden lag, always smooth.
With SYNC-ON, the db operation like this:
1.open db
2.1. write a record/do a transcation
2.2. fsync()
2.3. write a record/do a transcation
2.4. fsync()
.....
3.close db/fsync()
with SYNC-OFF, operation like this:
1.open db
2.1 write a record/do a transcation
2.2 write a record/do a transcation
....
3. close db/fsync()
So, no-sync can significantly save IO time.
Click to expand...
Click to collapse
Patch for libsqlite.c:
http://forum.xda-developers.com/showpost.php?p=12695464&postcount=1966
Code:
diff -urNp external/sqlite/dist.origin//sqlite3.c external/sqlite/dist//sqlite3.c
--- external/sqlite/dist.origin//sqlite3.c 2011-01-07 15:26:32.000000000 +0800
+++ external/sqlite/dist//sqlite3.c 2011-01-07 15:27:55.000000000 +0800
@@ -34761,7 +34761,7 @@ SQLITE_PRIVATE int sqlite3PagerOpen(
pPager->readOnly = (u8)readOnly;
/* pPager->needSync = 0; */
assert( useJournal || pPager->tempFile );
- pPager->noSync = pPager->tempFile;
+ pPager->noSync = 1;
pPager->fullSync = pPager->noSync ?0:1;
pPager->sync_flags = SQLITE_SYNC_NORMAL;
/* pPager->pFirst = 0; */
@@ -65838,7 +65838,7 @@ static void attachFunc(
sqlite3PagerLockingMode(pPager, db->dfltLockMode);
sqlite3PagerJournalMode(pPager, db->dfltJournalMode);
}
- aNew->safety_level = 3;
+ aNew->safety_level = 1;
aNew->zName = sqlite3DbStrDup(db, zName);
if( rc==SQLITE_OK && aNew->zName==0 ){
rc = SQLITE_NOMEM;
@@ -97124,7 +97124,7 @@ static int openDatabase(
** database it is 'NONE'. This matches the pager layer defaults.
*/
db->aDb[0].zName = "main";
- db->aDb[0].safety_level = 3;
+ db->aDb[0].safety_level = 1;
db->aDb[1].zName = "temp";
db->aDb[1].safety_level = 1;
So the basic idea is to limit IO-interaction by disabling fsync.
Interesting, I figured it would have been in one of the kernel modules.
Ok, I have been able to compile the CM9 source (for the galaxy nexus, because the tutorial was for that one) including the sqlite source...
First test was now 36,6 secs which is pretty nice, have to check for other issues (and will compile for TF201 if I can soon). The semi patch caused a number of force closes so we'll have to see how this one goes.
But at least happy I was able to compile
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Code:
Device: Transformer Prime(TF201)
ROM: AOKP B38
Kernel: Motleys running at 1.8 set to performance governer for testing
Tests: ( All tests done Run 1 after fresh boot, Run 2 immediatly after, all set to performance governer )
Couldn't get the damn formating to look right in the post ... check the image for results.
RubenRybnik said:
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Code:
Device: Transformer Prime(TF201)
ROM: AOKP B38
Kernel: Motleys running at 1.8 set to performance governer for testing
Tests: ( All tests done Run 1 after fresh boot, Run 2 immediatly after, all set to performance governer )
Couldn't get the damn formating to look right in the post ... check the image for results.
Click to expand...
Click to collapse
What about actual use performance? Is web browsing lag gone? What about switching apps?
I'm a little hesitant about the data stability... with my luck I'll have rock solid stability until the ONE TIME I actually need it and lose important data
Updated main post...
This should be in dev section?
Looks promising, thanks OP.
Sounds very promising. Rooted people, start testing!
sweet. going to try it tonight!
---------- Post added at 01:33 PM ---------- Previous post was at 01:13 PM ----------
RubenRybnik said:
Wow ... thanks for posting this ... I've edited the sqlite source and compiled the binary for AOKP B38 below are my setup details and test results. So far everything is stable, no FCs in the past 45 min and things are much faster. I have no idea whats up with Antutu's SD Card reads, that's outrageously high lol ... Can't say I trust that ;o) . Otherwise great hack. I wouldn't recommend running this if you have a need for solid data stability, I haven't seen anything yet, but ending all those syncs may cause problems down the road, I don't know. Since I flash regularly I don't really mind it, loving the speed! Also found some other sqlite optimization tips( Cache size and some others ) I may try to add in after I run it for a day as is and see how stability is. Again, thanks to the OP, great find!( so far )
Click to expand...
Click to collapse
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Tempie007 said:
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Click to expand...
Click to collapse
Posted this in the TFP's AOKP thread in that 'other' forum:
I'm seeing some great results personally. Chrome on prime seems really responsive, apps launch pretty much instantly, haven't seen a desktop redraw on Nova the whole time. I have an image folder with about 300 wallpaper images, opening that in quickpic in the past has been pretty slow( several seconds ), now that is almost instantly done, all thumbnails before I blink lol.
Now I'm not saying this is all the sql patch I did at all, unfortunately I didn't put much time into using Montleys new kernel in a 'real world' case, I only benchmarked with his kernel then applied sql patch and benchemarked again( still using his kernel ). So perhaps I'll flash back tonight just to see if I can gauge how much the patch vs kernel is doing.( Thanks again Motley! ).
As for side effects, I installed Chrome last night so I could test, had about a 2 second freeze at the end of it installing, but came back and was fine after. Haven't seen any other freezes. I did 'loose' wifi for about 20 min last night. I was connected to the wifi the entire time, but even a reboot and net wouldn't work on the Prime, not sure what happened, or if it's related, but seemed to have 'fixed' itself after 20 min last night.
Click to expand...
Click to collapse
Tempie007 said:
sweet. going to try it tonight!
---------- Post added at 01:33 PM ---------- Previous post was at 01:13 PM ----------
Regarding your screenshot, the 1k inserts: After the SQL Patch those scores are on par with the other devices where we've seen benchmarks from (less than 1 second, which is literally 100 times better.. )
I don't believe in coincidence
Can it be that on those devices FSync is allready disabled, or bypassed only in some cases?
Anyhow i am realy curious if this makes stuff feel better
Click to expand...
Click to collapse
If it is, it is not done in the library itself...
I also tried the libsqlite files from the SGS3 for example and copied them to the prime, but that didn't help much... So if fsync is handled differently on those devices it is done in a different place.
This is just a workaround for (part of) the problem... The real issue is elsewhere. I mean, the CM9/AOKP/AOSP roms use the same source for the differnt devices yet the issues are not the same on all of them.
So somewhere in the kernel code? Or another level, the controller for example. As the HTC One X performs decent it seems that it's not (JUST) the tegra3 but some of the other components.
Ah well, maybe tonight I can try the full wipe and reinstall and see if that helps anything.
Booting time doesn;t improve with this mod, titanium restores improve a bit but nothing extreme (20-25% faster is my guess) so there IS more going on. My guess is the used memory is at least part of the problem.
Some SD benchmarking indicating the memory used isn't the best one :/ (Done with the 'Device Performance' benchmarking app)
Asus TF201:
[email protected]/mnt/sdcard (=internal)
Max Write: 14,4
Mean Write: 12,1
Min Write: 9,4
Max Read: 28,8
Mean Read: 23,2
Min Read: 14,9
[email protected]/Removable/MicroSd (=external)
Max Write: 14,7
Mean Write: 11,4
Min Write: 9,9
Max Read: 14,6
Mean Read: 12,7
Min Read: 9,0
SGS3:
[email protected]/mnt/sdcard (=internal)
Max Write: 26,7
Mean Write: 25,3
Min Write: 23,9
Max Read: 43,8
Mean Read: 42,2
Min Read: 39,4
[email protected]/mnt/extSdCard (=external)
Max Write: 10,6
Mean Write: 10,0
Min Write: 9,6
Max Read: 13,8
Mean Read: 10,6
Min Read: 6,2
Is it possible to make an intelligent fsync where it basically syncs after some clock time after the last db write or inserts an fsync with a high count of writes?
Hey guys,
I came across this in teh portal and am not sure if it actually works on my prime (Stock rooted OTA JB). I would love to see how it fares for the rest of you. Here is the information from the OP. All credit to OP lambgx02 and Ryuinferno.
Instructions: FOLLOW THE INSTRUCTIONS IN THE SECOND QUOTED POST IF YOU CANNOT FLASH FILES FROM RECOVERY OR ARE ON STOCK FIRMWARE
Here is the OP:
lambgx02 said:
Hey everyone,
So, I was experiencing significant lag as we all do from time to time, and decided I was going to get to the bottom of it.
After tracing and debugging for hours, I discovered the source of 90% of Android's lag. In a word, entropy (or lack thereof).
Google's JVM, like Sun's, reads from /dev/random. For all random data. Yes, the /dev/random that uses a very limited entropy pool.
Random data is used for all kinds of stuff.. UUID generation, session keys, SSL.. when we run out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data.
So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.
Result? I have never used an Android device this fast. :good:
It is literally five times faster in many cases. Chrome, maps, and other heavy applications load in about 1/2 a second, and map tiles populate as fast as I can scroll. Task switching is instantaneous. You know how sometimes when you hit the home button, it takes 5-10 seconds for the home screen to repopulate? Yeah. Blocking on read of /dev/random. Problem solved. But don't take my word for it .. give it a shot!
Update!
I've built a very simple Android app that bundles the binary, and starts/stops the service (on boot if selected). I'll be adding more instrumentation, but for now, give it a shot! This APK does not modify /system in any way, so should be perfectly safe.
This is my first userspace Android app, so bear with me!
Note that this APK is actually compatible with all Android versions, and all (armel) devices. It's not at all specific to the Captivate Glide.
Caveats
There is a (theoretical) security risk, in that seeding /dev/random with /dev/urandom decreases the quality of the random data. In practice, the odds of this being cryptographically exploited are far lower than the odds of someone attacking the OS itself (a much simpler challenge).
This may adversely affect battery life, since it wakes every second. It does not hold a wakelock, so it shouldn't have a big impact, but let me know if you think it's causing problems. I can add a blocking read to the code so that it only executes while the screen is on. On the other hand, many of us attribute lag to lacking CPU power. Since this hack eliminates almost all lag, there is less of a need to overclock, potentially reducing battery consumption.
If you try it, let me know how it goes.
ROM builders - feel free to integrate this into your ROMs (either the .apk / application, or just the rngd binary called from init.d)!
If anyone's interested, I've launched a paid app on the Play store for non-xda users. As I add features I'll post the new versions here as a thanks to you guys (and xda community at large for being such a great resource). But if anyone's interested in the market's auto-update feature, just thought I'd mention it.
Cheers! :highfive:
Click to expand...
Click to collapse
Here is another informational post from TODAY with installation instructions that worked for me (unlike the APK in the OP).
Ryuinferno said:
First things first I am not the OP but things need to be sorted out...Ok...this thread is starting to get more and more attention, which is good because with more people to test things out, the more feedbacks and the more improvements can be done...however, the thread is now cluttered by tons on unhelpful posts, like "how to use this", "do I need root" etc...useful posts get pushed wayyy behind, until it is hard for people who are really trying to discuss to keep track...so I am here to answer the basic questions:
Do you need root for the app?:
Yes
Can it work on xxx device?:
Yes, as long as your device is arm based
Where to download the app?:
Here: http://forum.xda-developers.com/attachment.php?attachmentid=1477944&d=1352786461
Or search Play Store for a donate version...
The other 2 attachments are the rngd binary and a diff patch, which are not really required for end users...
How to check whether it is working or not?:
In terminal emulator, type
Code:
watch -n 1 cat /proc/sys/kernel/random/entropy_avail
You should get values around 3000++ to 4000++...
Set on boot does not work?:
It does, just that the app does not show it properly...it is a known bug...to really confirm, use the terminal emulator method above...
Do I have a risk of bricking my device?
No because the app won't modify system files at all...anything just uninstall...
For the zip, it only adds files to your system partition...does not modify any, so if you want to stop using this, you can disable it via the extended menu script...
It does not do anything/It is placebo/I see no improvements/It is awesome!/Wow!:
Well, this is not constructive or helpful...NOT AT ALL...keep in mind that this is still a WIP...research and discussions are still going on...if it is not working or you feel no change or a great improvement, please describe more and explain...which a lot of others are already doing so......keep it up!
For more answers, read this post by my pal pepoluan...
http://forum.xda-developers.com/showpost.php?p=36234571&postcount=444
And for those who prefer to run this via a script and init.d, read on...
=======================================================================================================================
UPDATE: Seeder_v6 is out, I improved the detection of whether rngd is running or not (the previous method was not that accurate), and I removed unnecessary lines...previous users can just flash over...
Download and flash: http://www.androidfilehost.com/?fid=9390248398092764097
How to use this script?:
After flashing, launch terminal emulator and type
Code:
su
seeder
You will get a menu like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
NOTE: There will be NO app after flashing! This only installs the necessary binaries and scripts...
For those who cannot install via recovery:
You get a status 0 error -> replace the update-binary in Seeder_v6.zip with one from another zip that works with your device
OR
Use the new installation method!
Instructions:
1. Download Seeder_v6_non-CWM.zip from here: http://www.androidfilehost.com/?fid=9390248398092764098
2. Extract the zip, you will get a folder named "install"
3. Place the folder in the root of your sdcard (/sdcard)
4. Launch terminal emulator, type:
Code:
su
cd /sdcard/install
sh install.sh
5. Ignore any error messages (those are only warnings, only happens to current users)
6. You are done! The script will auto-delete the "install" folder as it is not required anymore...
Sample output:
NOTE: Please quote this post if you want to answer someone's question or share it elsewhere, so that people can get sufficient info and repeated answers do not have to be posted...thank you...
Click to expand...
Click to collapse
Personally, it installs for me, but I'm unable to get the init.d stuff to install (no support for this on Asus' stock rom). When running the terminal command line to monitor it, I get total values of 3000-4000. I'm not actually sure if it made a difference in my TFP performance.
What are your guys' experience?
Running aw1.5, I don't seem to find any difference in performance whilst the app is running it seems to drain battery life regardless of the screen being off or on, causes my prime to heat up overnight, causing 20-30% drainage
There's a simpler way to get the effects of the application. Bring up a terminal, and do something like:
cd /dev
mv random random.bak
ln -s urandom random
This will have the same effect - apps trying to read from /dev/random will get data from /dev/urandom instead - but it doesn't require any extra CPU time or kernel mods or anything. It does require root, but so does the original app.
Note 1: You may have to do this again if you reboot, or else add the above commands to a startup script. I'm not sure how the /dev directory is typically managed on Android.
Note 2: This (or the Seeder app) will degrade network security somewhat. Things like SSL depend on high-quality, unpredictable random numbers. The /dev/random interface guarantees these, but can be slow. The /dev/urandom interface doesn't guarantee cryptographically secure random numbers. If you do this, it's probably best not to use your table for, say, banking transactions, shopping, or other operations where you'd be in real trouble if people were snooping on your network connections.
That said, the odds of a cryptographic hack are, so far as I can see, fairly low. In general, attacks on Android would tend to be malicious trojan apps or such. But you should be aware of the risk.
I don't know yet if this change makes a real difference. I did it on my original Droid, but haven't evaluated it for long enough to be sure of anything. My TPrime isn't rooted (yet) so I can't implement it there.
sorceror171 said:
There's a simpler way to get the effects of the application. Bring up a terminal, and do something like:
cd /dev
mv random random.bak
ln -s urandom random
This will have the same effect - apps trying to read from /dev/random will get data from /dev/urandom instead - but it doesn't require any extra CPU time or kernel mods or anything. It does require root, but so does the original app.
Note 1: You may have to do this again if you reboot, or else add the above commands to a startup script. I'm not sure how the /dev directory is typically managed on Android.
Note 2: This (or the Seeder app) will degrade network security somewhat. Things like SSL depend on high-quality, unpredictable random numbers. The /dev/random interface guarantees these, but can be slow. The /dev/urandom interface doesn't guarantee cryptographically secure random numbers. If you do this, it's probably best not to use your table for, say, banking transactions, shopping, or other operations where you'd be in real trouble if people were snooping on your network connections.
That said, the odds of a cryptographic hack are, so far as I can see, fairly low. In general, attacks on Android would tend to be malicious trojan apps or such. But you should be aware of the risk.
I don't know yet if this change makes a real difference. I did it on my original Droid, but haven't evaluated it for long enough to be sure of anything. My TPrime isn't rooted (yet) so I can't implement it there.
Click to expand...
Click to collapse
This amazes me! A knowledgeable person who hasn't rooted their Prime?!?! Good god man!
seeknom said:
This amazes me! A knowledgeable person who hasn't rooted their Prime?!?! Good god man!
Click to expand...
Click to collapse
Mine's working well enough for me (haven't had the horrible problems others report, just occasional ANRs on the browser), and I want to retain warranty coverage just in case. Plus, I have other hack targets like a Raspberry Pi and such. Once the warranty expires, I will certainly unlock and play around with it.
---------- Post added at 12:29 PM ---------- Previous post was at 11:34 AM ----------
Update: see the Google developer thread here: https://code.google.com/p/android/issues/detail?id=42265
The symlink trick may not work on versions of Android past Gingerbread, except on some specific applications (Google Maps appears to be one). Looks like the Dalvik VM on Android doesn't read from /dev/random itself; but some of its operations may end up calling get_random_bytes() in the kernel. So seeding the entropy pool would be necessary in that case, and the symlink trick doesn't do that.
I actually ended up disabling it again and I didn't notice any change in performance. Didn't seem to do anything for me.
Sent from my HTC One X using xda app-developers app
Can you please add another option to your poll: "DON'T KNOW/CAN'T TELL"?
I'm running it on my Prime and my Note 2 with what seems to be at least a slight increase in responsiveness. The Note 2 is dang snappy by itself, and I'm running Energy on my Prime, which is a lot smoother than stock. I would be interested to see how it works with older, laggier devices. I may boot up an old handset and see how it works on there.
Sent from my Transformer Prime TF201 using xda app-developers app
It's working for me, my prime used to have that annoying 2-3 seconds lag when returning to Apex Launcher from apps (even with HB 1.5), but that's almost 90% gone with Seeder running. Not to mention my Gallery loads much faster
placebo.
It works on my M600 Zio quite well. On my Prime, I can't truly say. It seems a little more responsive but I've never really had lag on the Prime unless I was writing large files to the internal storage and trying to do something else at the same time (rarely ever happens anymore with clemsyn's kernel).
i prefer crossbreader. the rng they us is a bit more efficient, and it comes with a couple more mods. i havent used on my prime but i have noticed measurable improvements on my note 2 (i multi task a LOT of apps a LOT of the time). for now its only a cwm install and uninstall zip, but they plan on making an installation apk soon. another benefit of this is that it doesnt run every 5 seconds like seeder does. this one is set to 30, and still maintains entropy levels of 3700-4096, hovering mainly at the 4000 mark (at least for me and many users)
http://forum.xda-developers.com/showthread.php?t=2113150
thanks, a great tool.
does it really work
enkyll said:
does it really work
Click to expand...
Click to collapse
give it a try your self, no harm in trying~
This is a script made by a member on AndroidForums originally for the LG Leon. We noticed that the CPU doesn't fall below 800mhz at all regardless of being under load or idle. This causes alot of battery drain since the CPU is running for literally no reason. I noticed the same problem on my Grand Prime G530T as the two devices share the same CPU.
This script will tune the CPU frequencies to drop to 200mhz when idle and fixes the time spent at higher frequencies, spreading the load across the cores more evenly for sustained performance and better battery life.
Instructions (root required obviously):
Download the script and extract it
Install SManager from the Play Store
Locate and select the MSM8916.sh file
At the top select SU
Hit RUN and allow permissions if asked
To see the difference, use a kernel tuning app (Kernel Adiutor I recommend) and watch the cores before and after running the script. It really does make a significant difference.
Credit to Bichofelix at AndroidForums for the script
Edit: fixed the script, now will keep max freq at 1190mhz instead of 998mhz
Edit 2: added sample screenshots of projected battery life
Hi, my device is G530HXCU. I also noticed on CPU-Z app that my device CPU doesn't fall below 800mhz. Tried using this script by following your procedures but the SManager shows "swapon failed for dev/block/zram0" when I run the script, just wanna ask if it is normal? Though when I closed all other apps on the task manager, my device CPU is now shown as 200mhz in CPU-Z. It seems like it worked. Thank you.
slasherkev said:
Hi, my device is G530HXCU. I also noticed on CPU-Z app that my device CPU doesn't fall below 800mhz. Tried using this script by following your procedures but the SManager shows "swapon failed for dev/block/zram0" when I run the script, just wanna ask if it is normal? Though when I closed all other apps on the task manager, my device CPU is now shown as 200mhz in CPU-Z. It seems like it worked. Thank you.
Click to expand...
Click to collapse
Yeah, the swapon thing can happen if your kernel (I think) doesn't support swap memory/zram. My G530T with the custom root kernel does and I don't receive this error, but it won't hurt anything if that particular part of the script doesn't run.
Enjoy the script and let us know how your device is faring with battery and performance. I'm a heavy gamer and from personal experience I get the same amount of performance and better battery, letting me play harder for longer ^_^
Hi, just wanted to share some feedback while using it. It greatly helps with reducing the battery drain and I really loved it, but on my G530H device, I need to run this script again whenever I reboot my phone. Though, when I did press the "boot" icon beside the "su" icon in the SManager and run the script again, it somehow solves the problem. However, the other problem that I've seen so far is that the maximum cpu of my device becomes 998mhz only, so I need to overclock it using a CPU controller app (I used No-frills CPU Control in playstore) to make it 1.19ghz and it worked. Is there anything I can do to help you fix that in the script so I won't need to use any CPU control app? Thank you very much I'm just a newbie here.
slasherkev said:
Hi, just wanted to share some feedback while using it. It greatly helps with reducing the battery drain and I really loved it, but on my G530H device, I need to run this script again whenever I reboot my phone. Though, when I did press the "boot" icon beside the "su" icon in the SManager and run the script again, it somehow solves the problem. However, the other problem that I've seen so far is that the maximum cpu of my device becomes 998mhz only, so I need to overclock it using a CPU controller app (I used No-frills CPU Control in playstore) to make it 1.19ghz and it worked. Is there anything I can do to help you fix that in the script so I won't need to use any CPU control app? Thank you very much I'm just a newbie here.
Click to expand...
Click to collapse
As stated in the OP, its not my script. But I went ahead and did it for you. Redownload the file and do the same as before. Setting the Boot option in SManager will run the script at boot after the system loads and the apps can gain SU permissions
Thanks for the tip and and glad you enjoy!
Added screenshots to the OP as proof of battery saving with the script.
Note: This usage was actually with an app called Resolution Changer that allowed me to use my screen in 720x1280 resolution, higher than stock which is 540x960. I also have Viper4Android installed with the highest audio driver available for it. These mods actually add more stress on the CPU, GPU and battery which would cause more drain. But as you can see...
I am also using a personally rebuilt rom that isn't ready for release yet as I'm having issues building it.
Who needs a 4000mha battery when you know how to use your system?!
Hello guys! I'm posting this now as I was searching on the Internet about Qcomm msm8916 devices! One tip I can give you as I learned some things, is to learn to build your device's kernel from source if your vendor has released it and remove the stock cpufreq limit API, as it is common in qcom. This API simply locks the frequency above some values to seem more snappy, but also reduces battery life in general! So it is common to sacrifice battery for speed and vice versa.. As you will see there are lots of posibilities also if you search the ramdisk for "optimizations" in frequencies that are done there, and change them to your liking! Happy modding! Cheers!
Nick Verse said:
Hello guys! I'm posting this now as I was searching on the Internet about Qcomm msm8916 devices! One tip I can give you as I learned some things, is to learn to build your device's kernel from source if your vendor has released it and remove the stock cpufreq limit API, as it is common in qcom. This API simply locks the frequency above some values to seem more snappy, but also reduces battery life in general! So it is common to sacrifice battery for speed and vice versa.. As you will see there are lots of posibilities also if you search the ramdisk for "optimizations" in frequencies that are done there, and change them to your liking! Happy modding! Cheers!
Click to expand...
Click to collapse
Nice bit of info there, but this script actually furthers those optimizers to reduce the number of cores needed to run processes and at lower frequencies. If it doesn't need it, your wasting performance and battery. This script helps regulate core speeds and cores online depending on what your doing using the interactive governor, which appears was not setup properly by the phone manufacturer of the device containing the msm8916 chipset.
I tried using it in CM12.1 unofficial rom for G530H and it works. I also think it helps reduce the appearance of deadlock bug for that rom. I edited the script and set the maximum cpu value to 1190400 instead of 1190000 because my device cpu is not going up to 1.19ghz when the script is only set to 1190000 so I tried to make it higher and it solves the problem.
Does it work on all MSM8916-based devices ?
What is the point of going under 800MHz? CPU takes same voltage on 200MHz and 800MHz.
I have a dual boot Android 5.1/Win 10 tablet (the Onda oBook10) that I recently managed to acquire root on (for any owners of this device that would like to know how, I'll be posting a guide soon). This thing has 4 gigs of RAM, but starts kicking apps out as soon as 1 GB is occupied. I've tried setting minfree using both Kernel Adiutor and by echoing manually to /sys/module/lowmemorykiller/parameters/minfree, but neither has any effect. I know that this change doesn't persist across reboots on any Android, but in this case, it has no effect even on the current session. What's even stranger, going by the default values that have been set, there shouldn't be any issues at all - it's actually less aggressive than most other devices I've seen. The values are:
Code:
13107,16384,19660,22937,26214,32768
According to Kernel Adiutor, that translates to (in MB):
Code:
51,64,76,89,102,128
Yet, running apps shows 2.8 to 3.1 GB free constantly, even though apps are reloading.
Does anyone know what might be causing this? It's an x86 device, in case that's relevant. I have access to the boot image (in case it's some kind of kernel flag), and can unpack to ramdisk and zImage, but I have no experience with kernels, and have no idea where to even begin looking; if someone could point me in the right direction, that would be awesome.
Thanks,
SirVer