Related
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
I do my best
I do my best ... with the "limited space" we're given for Thread Titles on the forum.
~enom~
I support this though I find it unnecessary. The new beginner user will most likely READ atleast the first post of the thread and they will know what the ROM is based off of. The end user will of course know to read the thread before doing any flashing of any kind so organizing mod rom versioning isn't a necessity. It's convienent but not necessary
I support this because it would make ROM catalogs easier to build, which would benefit the whole community.
why not just post what android version the rom is based on in the first post. First post should always hold the most info anyways.
Since this thread hasn't been moved from the Dev section so far.
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
alritewhadeva said:
The end user will of course know to read the thread before doing any flashing of any kind
Click to expand...
Click to collapse
rofl. Funniest thing i've read all week.
+1
how about shorthand naming such as
for example:
CyanogenMod = CM-AOSP1.6r1-v4.20
If you're talking about cyanogen mod, you might want to add a couple more zeroes at the end. Anyway, I had proposed this too a while ago. I like your format, and I'll go one better; let's do cook-androidVersion-buildVersion-feature.bugfix
for example, the build I made this morning would be "jm-1.6-Donut eng.jubeh.20090930.070211-0.0"
jm is what I use for my builds (short for jubehMod)
1.6 is the current android branch (as per build.prop, no 1.6_r1 yet)
Donut eng.jubeh.20090930.070211 is the build number the compiler assigned to my build, people who work off of modding factory releases or build for dream_open are the ones who usually come up with things like CRC or DRC etc, I build for "AOSP for Dream" (it's a new "vendor" added)
first 0 is feature number, at this point my build is nothing but stock AOSP donut, no Google apps, no a2sd, no netfilter, no compcache, no bfs, just stock donut, so say I were to add a2sd, then I'd go up to 1, as I would have added one or more features (and this would be listed at the change log), basically, anything added that improves the build (and that's not a fix) is a +1 to feature
second 0 is bugfix. For example, right now my build works correctly in every sense, but I have a problem with the video camera where video is of very poor quality (real problem, I'm trying to figure it out), so say i get it fixed, then my bugfix number would go up 1, so basically, anything changed in the build strictly because it didn't work as intended is a bugfix
the last two numbers would be allowed to go past 9, so no more pressures to add .1s at the end like cyanogen was doing to prevent jumping to build # 4.2
karthikjr said:
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
yes just bench mark. its much better than benchmark pi only test the cpu really
by the way, I've been saving pretty much all roms that have been posted here (notable exceptions are haykuro's, jf's, and theduded's roms, I haven't been here THAT long) and I have them all saved on my computer separated by /cook/build/ for the Dream roms and /build/cook/ for the Hero ports. I guess I could run a quick filesystem lister and upload that list for people to see so they can sort of get an idea what mod release corresponds to what build
Here we go, I had to upload it inside a zip because of the stupid 2kb limitation on text files (this is 10kb)
lbcoder said:
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
Click to expand...
Click to collapse
................................
Hi jubeh,
Thanks, this kind of cataloging is exactly why the OP's suggestion will be helpful.
karthikjr said:
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
I'm not so sure that we do...
I think that that should be more of a "details" thing.
Maybe we can go with "name-officialversion-modversion[-custom]" (square braces mean optional). Name might be a good place to keep modelnumber (I assume you mean by that "dream", "magic", "hero", etc.),
i.e.: supercustomrom(DREAM)-1.6r1-0.0.0.0.0.0.0.1-cc_swap_a2sd
Kifno's HeroC Universal Scripts v2.0.1
PLEASE READ THE ENTIRE FIRST POST BEFORE POSTING
THE CREDITING/PERMISSION ISSUE IS DONE AND OVER WITH EVER SINCE THE V1.x THREAD SO PLEASE NO MORE POST ABOUT THAT, OR YOU WILL BE REPORTED TO A MOD! ALSO I DID NOT JUST COMPILE A BUNCH OF MODS TOGETHER! IF YOU READ THE CREDITS YOU'LL SEE I ASKED TO USE THEIR IDEAS AND I IMPROVED THEM AND INCLUDED THEM ALONGSIDE MY WORK! SO PLEASE NO POST ABOUT I HAVEN'T DONE ANYTHING BECAUSE IT IS OFFENSIVE TO ME WHEN I KNOW I HAVE DONE EVERYTHING IN THIS SCRIPT FOR OUR HEROES, FROM MY CUSTOM VALUES TO THE IMPROVEMENTS OF OTHERS IDEAS OF WHICH I HAVE CREDITED AND GOT PERMISSION FROM AND SUBMITTED MY IMPROVED VERSION TO.
Thanks
- Kifno
What did I do?
- Read change log
My Explanation for the tweaks/scripts
Code:
Yes these are the tweaks I apply. They are what I think are the best
values for the file(s). Now I'll go into detail as to what each file is and why I set
a new value for it. If you don't like my opinion as to why my new value is
better please explain in a positive manner why you think so or just well...
then, no offense but just keep it to yourself. If you can't say anything
that is constructive POSITIVE critism without using language that could lead to
an argument/provakative language then please don't post here. Now on to the
explanations.
[B]Kernel Tweaks:[/B]
This specifies a period of time that the kernel gives a process that is holding a
file lease. After it has sent a signal to that process notifying, it that another
process is waiting to pen the file. In simpler terms this means that the kernel
has given the process a set amount of time it can hold a file after another
process has notifying it that it wants the file. The deafult had the time higher. I
set it lower. Although it doesn't make much of a difference, ever millionth of a
second counts :D
[CODE]/proc/sys/fs/lease-break-time
This enables cfq compatibility with older kernel models. This results in better
performance, for example more smoothness in apps and the launcher
Code:
/proc/sys/kernel/sched_compat_yield
This value has to correspond with the file-max value so this is raised according
to the value of the file-max. Why did I raise the file-max? Keep reading silly
Code:
/proc/sys/kernel/ngroup_max
Disables some annoying cfs scheduler feature (which is why I don't use the cfs
scheduler in my tweak, I use the noop scheduler) whic increase the UI's
performace just a bit.
Code:
/proc/sys/kernel/sched_features
Sets the maximum number of file-handles that the android kernel will put aside
for other use, share, or put in memory for other use. Usually increasing this
value is a good thing compared to the default value. Which in our case, it was.
If our kernels had an inode file we'd want the value of that to be 2-3 times as
much as the file max. Its a good tweaking rule I thought I'd let you know just
in case you're on linux
Code:
/proc/sys/fs/file-max
This is the max percentage of active processes that can be filled with dirty
pages before the pdflush begins writing them This MAY OR MAY NOT be the
default value for most kernels, but just in case it isn't I set it anyway. Why?
Becuase I want to make sure that if the dirty pages is about 19MB - 40MB of
our RAM, that pdflush begins writing
Code:
/proc/sys/vm/dirty_background_ratio
How agressively memory is "swapped" between disk and swap space.
Code:
/proc/sys/vm/swappiness
Lowering this is a good thing if on a system with slow I/O speeds between the
disk. But if this is lowered too much the I/O will get "constapated" and just
slow the phone down.
Code:
/proc/sys/vm/dirty_expire_centisecs
Doesn't do much but messing with the pdflush's timing of things. Little improvement but everything adds up
Code:
/proc/sys/vm/dirty_writeback_centisecs
Management of the phone's processes by setting a max amount of memory the
phone allows for dirty pages before stopping the processes writing.
Code:
/proc/sys/vm/dirty_ratio
Sets kernel priority for getting/releasing inodes and dentry cache files.
Higher = getting inodes and dentry cache files back more quickly
Lower = releasing inodes and dentry cache files a bit more quickly
Code:
/proc/sys/vm/vfs_cache_pressure
Changes the govenor depending on screen state
Code:
$*GOV
Changed timeslice lenght for better performance when using the phone, and
bettery battery when you aren't using the phone (screen off).
Code:
/proc/sys/kernel/sched_latency_ns
/proc/sys/kernel/sched_min_granularity_ns
/proc/sys/kernel/sched_wakeup_granularity_ns
Cpu frequencies. Pretty simple to explain
Code:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
Amount of time before the interactive governor decides to change the cpu
speed.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/interactive/min_sample_time
This is how often the kernel changes the frequency.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate
This is the max rate at which the kernel can change frequencies.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate_max
Thi is teh min rate at which the kernel can change frequencies.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate_min
Average CPU usage from kernel's sampling rates which help it determine
wheather or not it should increase the CPU frequency.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/conservative/up_threshold
This is what I use to find the battery percentage for the battery percentage
profile.
Code:
$capacity
This is what I use to find the temperature for the temperature profile.
Code:
$temp
Determines if phone is sleep or awake for screen state profile
Code:
$sleeping/$awake
This is the amount of power that was given towards wifi. I just upped the
amount a bit BETTER WIFI WOOHOO
Code:
/sys/module/acpuclock_arm11/parameters/pwrc_khz
/sys/module/acpuclock_arm11/parameters/wfi_khz
I/O Scheduler Tweaks:
IMO the noop scheduler is better for our read and write speeds. Simple as that.
And what more than a better scheduler for read and write speeds to go along
with the sd card speed tweaks?
Code:
echo noop > /sys/block/*/queue/scheduler
Set so that the phone's process, ram, or any other request won't get out of
order. This improves the performance because it helps our internal drive and
extral drive (if using apps2sd or data2ext or data2sd). How think of it as
organizing the request a little bit better than the default value This is more
of a being safe thing in fact, but also a little extra performance didn't hurt
anyone did it?
Code:
/sys/block/mmcblk0/queue/nr_requests
Network Tweaks:
These change the DNS server to 0.0.0.0 which in fact helped my mobile data
speeds go up by about 50-100kbps This DNS server was better than
google's or opendns (but I've always had problems with opendns). Though
google's dns server came close to being the better of the three this DNS server
was the best after being tested many times
Code:
nameserver 0.0.0.0 /etc/resolv.conf
The following are the combination of strings and values that I played with in the
beginning days of this tweak so configure our network speeds. It took about 6
hours of testing to come up with the best combination for the heroc And like
I've asked and I've said about at least 20x when asked, exactly how is our
CDMA network affected by these values when they aren't even meant for it?
They just do, now shh and enjoy your better 3G speeds But seriously ask
someone in the networking field or someone who works for sprint but is into
rooting androids (so you won't get into trouble because of hacking their data
tower speeds they give out to our herocs ). I did and it has something to do
data towers, I can't explain exactly how because once I heard that I was so
excited I just stopped listening as well
Code:
ro.ril.hsxpa=2
ro.ril.gprsclass=8
ro.ril.hep=1
ro.ril.hsdpa.category=24
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=3
wifi.supplicant_scan_interval=20
How frequently the keepalive probes are sent out is determined by tcp_keepalive_intvl This is value is dependent upon tcp_keepalive_probes as well, which determines how many probes are sent out. This determines the time not to kill the connection. I lowered this value so connections will be killed faster.
Code:
tcp_keepalive_intvl
tcp_keepalive_probes
Time to hold sockets, which I lowered.
Code:
tcp_fin_timeout
Socket receive buffer. Increased to increase sockets received from network.
Code:
rmem_default
Socket send buffer. Increased to increase sockets sent to the network.
Code:
wmem_default
Maximum socket receive buffer. Increased to increase the total amount of sockets we can receive from the network.
Code:
rmem_max
Maximum socket send buffer. Increased to increase the total amount of sockets we can send to the network.
Code:
wmem_max
Memory Tweaks:
This is the tweak I used to configure our internal task killer. I had to experiment
with this a lot becaue certain values made music playback very choppy when
the screen was in sleep mode. But at last these are the values I came up with
to keep our free ram high while not interfering with everyday usage too much
Code:
echo "3072,6144,9216,21000,23000,25000" > /sys/module/lowmemorykiller/parameters/minfree
SD Card Tweaks:
This is the cache of the sd card. This was set to 128 so I bumped it up to 1024. Other values may be better for your phone and it's sd card but this is the
most compatible across the board. Still a performance increase but just not the
optimal value. Why? Because all heros are different as well as that plust the sd
card everyone is using
Code:
read_ahead_kb
[/CODE]
Requirements:
- Rooted HTC Hero CDMA
- Kernel w/ Interactive, Smartass, Conservative, Powersave, Ondemand, and Performace Governors (Grab deca kernel and compile from source if not using cyanogenmod based roms, or use sobe's kernel)
ATTENTION
DO NOT, I REPEAT, DO NOT USE SETCPU/OVERCLOCKWIDGET/COLLIN_PH/DECA'S BATTERY TWEAK, OR ANY BATTERY TWEAKING/CPU OVERLOCKING UTILITIES/SCRIPTS WITH THIS MOD!!!!!! WARNING USE THIS MOD AT YOUR OWN RISK!!! I TAKE NO RESPONSIBILITY FOR WHAT HAPPENS TO YOUR PHONE IF SOMETHING GOES WRONG! ALTHOUGH IF SOMETHING DOES HAPPEN I WILL HELP YOU AS MUCH AS POSSIBLE!!!
INSTRUCTIONS
Installing Instructions (Recovery Menu):
Difficulty: Easy
Reboot Recovery
Download and Flash Kifno's Universal HeroC Script
REMOVED UNTIL RELEASE OF V3.0.0 SOMETHINGS WERE BROKEN IN ROMS WITH THIS RELEASE.....IF YOU HAVE V2.0.1 DON'T USE IT WAIT UNTIL V3.0.0
- THANKS
Wipe cache, and dalvik-cache
Reboot into system
Enjoy
Removal Instructions (Recovery Menu):
Difficulty: Easy
Download the removal zip for latest version
Get It Here
Reboot Recovery
Flash it
Reboot
TESTED AND SUCCESSFUL ON
- Cyanogenmod 7.0.2
- NfiniteFX's Stock Rom
- LiquidSense 2.1.1
- Kifno's 2.1 Sense Roms
- Aosp Gingerbread
- GingerSense/Rock Steady
- Aosp Froyo
- CM6.1
TESTED AND SOMETIMES FAILED (BOOTLOOP/LAGGING) ON...
NOTE: If lagging with latency tweak builds, use the no latency tweak builds.
- Works on Every Rom
Change Log
Code:
4/27
- ALL BY KIFNO!!!!!!!
- Documentation for my opinion of what all my tweaks/scripts do. (I say opinion because I may or may not be correct for all of my explanations. If I am wrong please let me know, so that I can correct it so that others will not learn false information).
- setCPU, collin_ph, overclockwidget, CM7's cpu settings, or any other battery tweak/cpu overclocking utility, REPLACEMENT. This is not to be used with any of those utilities while using this or you will encounter many problems.
- mobile network and wifi speed boost ranging anywhere from 175%-400% speed gains. The percentage amount increased is determined by many other factors (the data tower in your area, your phones condition, the wifi connection, etc)
- Smoother UI
- More Free RAM
- Memory Settings Optimizer
- Any kernel tweak-er
- DroidX Market Tweak COMING SOON
- GPU Composition instead of MDP Composition
- Extended Battery Life and/or Increased Performance as a result of the tweaks and my battery tweak/cpu overclocking utility replacement script
- Tweaked the I/O
5/2
- removed some junk
- made network speeds a bit more stable
- fixed the problem were my 98kiftweaks wasn't writing the values correctly (sd card cache fix improvement & io tweaks)
- adjustments to kifCPU so that there will be longer battery life :D
- added a removal and backup script
Donations
I want everyone who is has ever donated, or has thought of donating me or anyone else to know this. XDA is a place for everyone to learn, teach, and share their work and new findings for android. Donations are not a right on XDA they are a privilege. Donations were allowed for XDA members to give and receive as a way for someone who really appreciates the original poster's work and is a way for the donor to show their thanks by doing more than pressing the thanks button. This is something that the original poster should appreciate and follow up with a PM as a thanks for their thanks, and use that as a notification, that they should keep up the good work and they're doing good things for XDA. Again recieving donations is not a right it is a privilege, that the original poster shouldn't abuse by asking for donations but instead appreciate when recieved. Asking for donations is not right and it is looked down upon on XDA because it goes against the meaning of what XDA is all about. This is something I want everyone to understand before even thinking of donating to me or anyone else or when given a donation. Don't donate because the original poster comes off as asking for money, instead if you choose to donate, donate out of showing more appreciation for another's work and as more of a way to show that you care for their work. I want everyone to understand that.
- Kifno
Credits:
unCoRrUpTeD
Made base of the script when he converted the v0.9 build.prop edits in to a script.
brainmaster
SD Card cache IDEA. I improved it.
farmatito
IDEA for I/O scheduler tweaks. I improved them for our heroes.
montalbert
MOST of the network tweaks. I just changed the values so that it'd be optimal for our heroes.
FloHimself
Screen state IDEA for kifCPU
Okay gonna take it for a spin and see how it works. But I have a??? Does this mod preset the max/min cpu speed??? I use jm's kernel @ 710 max 691 min. But at work or when I'm in an area that has poor reception I bump it up to 768min 806 max. Am I able to still do this and use this tweak effectively??? Also does the removal zip from your prior tweak remove this?? Also to use the battery tweaks must I do the whole calibrate thing??? The reason I ask is I use the gf's data2ext mod and letting the battery discharge is a no go.
#Root/Hack-Mod_Always*
laie1472 said:
Okay gonna take it for a spin and see how it works. But I have a??? Does this mod preset the max/min cpu speed??? I use jm's kernel @ 710 max 691 min. But at work or when I'm in an area that has poor reception I bump it up to 768min 806 max. Am I able to still do this and use this tweak effectively??? Also does the removal zip from your prior tweak remove this?? Also to use the battery tweaks must I do the whole calibrate thing??? The reason I ask is I use the gf's data2ext mod and letting the battery discharge is a no go.
#Root/Hack-Mod_Always*
Click to expand...
Click to collapse
No it doesn't remove this I need to make a removal .zip asap. But You can just take the 768mhz zip and upzip it and change the cpu values in the /system/bin/kifCPU.sh file
just look for the the lines that effect the cpu speeds. If you don't know which ones do, then read my explanation for my tweaks
OH YEAH EVERYONE I ADDED MY EXPLANATION FOR TWEAKS If I am wrong about anything please, tell me asap so I can update it so people don't learn false information.
Glad to be on a fresh start with this
I'm gonna be all over this. Haha.
Please post feedback as to hours of battery life increase based on your normal usage and which build worked for you rom. Please post your rom and kernel you're using as well. and any other things you'd like for me to know as well. Thanks
flashing on aospCmod now (right after this nandroid finishes)
Haha. Outstanding!
Rom: CyanogenMod 7.0.2
Kif's Universal Script: Latency 768
Kernel: Sobe's AP5
Battery: Will post feed back when I get off work.
Network speed: Outstanding on my phone!
Keyboard response: before kid's tweak, laggy After kif's tweak, VERY! responsive.
UI: Speedy!
Haha. Feels like I just bought a new phone.
I can't wait to test this out on Rock Steady when I get home! Honestly I flash this on work hours. Ha. Yea I'm a flash freak like everyone else. I should just say I'm sick *cough cough* ha.
Outstanding work bro!
Will post more feedbacks when I get home.
Take care and God Bless.
I'm using one of Zen's kernels (710MHz)on NfiniteFX ROM. Can I use this? I'm not sure Zen's kernels have the governors you mention. Where can I get such a kernel, remembering that I am running Sense. I've read Zen kernels are usually best for Sense.
Thanks!
so far so good installed fine
downloads 35-50% faster on average on a few trials via 3g.
In regard to your explanation:
Code:
/sys/block/mmcblk1/queue/nr_requests
As stated previously in the old thread, this file has never and will never exist on the hero, because we only have one SD device.
This DNS server [0.0.0.0] was better than
google's or opendns (but I've always had problems with opendns)
Click to expand...
Click to collapse
0.0.0.0 is NOT a DNS. All this value does is force the phone to use whichever DNS the network specifies (which it may or may not be doing anyway).
Code:
ro.ril.hsxpa=2
ro.ril.gprsclass=8
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=24
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=3
You said to "ask someone in the networking field" about these values. Someone from the "networking field" (dhero) already chimed in (as did several other people) and told you that some of these lines don't even do anything. The only thing here that's probably making a difference in network speeds is the bitmask value (which is just setting all bits to 1, negating what they actually do).
For instance, I can tell you 100%, for a fact, that the "ro.ril.enable.dtm" line does nothing on the hero, because the entire point of this line is to enable simultaneous use of voice/data on GSM networks. CDMA networks have never been able to do this, and that's not something you can change
The line "ro.ril.enable.a53" also does absolutely nothing on our phones. A5/3 is an encryption algorithm, used on GSM networks. It has no use in CDMA devices, and was actually broken by hackers in recent history.
I've love to see some real documentation of how setting these values really makes a difference. The facts of speed tests are that (1) they are only testing your "burst" speeds which means they don't really answer many questions about long-term performance and that (2) they can vary wildly in the same time frame. I know that I have personally always had better EV-DO speeds than your scripts supposedly provide (sustained average 1.5-2mb/s downstream), and that all depends on signal range and nearby devices.
Right now I'm working on actually reverse-engineering the HTC RIL library to see what these values REALLY change. As far as I can tell, some of them never actually make a difference on the CDMA Hero and are just left over from the GSM Hero and other devices. They are read in from the prop file, but the variables which contain them aren't referenced by the CDMA code paths.
Code:
windowsmgr.max_events_per_sec=60
As stated previously in the old thread, this value does nothing because that's already the default value in the source code.
Code:
keyguard.no_require_sim=true
As stated previously in the old thread, this is already set in the build props.
Code:
debug.sf.hw=1
As stated previously in the old thread (and backed up by PROVIDING THE SOURCE CODE), this line does nothing because it's the equivalent of not specifying it at all. This is why we removed it from the CM build a LONG time ago. The ONLY time this line would EVER make a difference is if someone had deliberately set it to 0 beforehand, and as far as I know, no ROM (including the stock one) has ever shipped with 0 set.
The DEFAULT behavior of SurfaceFlinger is to always use the GPU when possible. The ONLY reason the "debug.sf.hw" line exists is for troubleshooting/debugging, for example when booting the emulator.
------------------------------------------
In regard to my own exploration of the zips provided (for reference I used the no-latency 691 zip):
You have a typo in your code.
Code:
CHECK_NOOP=` cat /sys/block/mtdblock3/queue/scheduler
The tailing backtick is missing.
Why are you providing busybox in your zip? The version you provide (1.15) is outdated; a newer version is already in CM7 and other ROM images. And the folder you're copying it to (system/sbin) doesn't actually exist.
By overwriting the init.local.rc script instead of appending your code to it, you are effectively breaking compcache in CM.
Your CPU profiles contain multiple infinite loops. This is bad practice. Your loops don't contain ANY sleep calls as far as I can tell, which means they run indefinitely, sucking up CPU cycles and battery. Your script should be sleeping on an interval.
The functions called by your infinite loop themselves contain infinite loops, which means that (as far as I can tell) they will never return and charging source changes will never be detected. Am I reading this wrong? Does this really work?
Blah blah blah..
Your scripts are working fine on my phone and others even though you've missed a few things here and there. The main thing is that your trying and trying leads to something even better. Looking forward to seeing v2.x and further.
I feel like I am on a creepy merry-go-round.....
Yet again kifno, when you could be an asset to the community simply by giving proper credits originally and saying that you used others work and made it better, you take all or most of the credit for yourself. If you want to help the community, do so by following the rules and common sense. FYI you cant "improve" brainmasters sd tweak because ALL it does is change the read_ahead_kb in sys/devices/virtual/bdi/179:0/read_ahead_kb. Now here's some links that users/mods/kifno would do well to pay attention to the dates of, these are also the only ones that I personally have reviewed recently, I would bet there are more:
http://andrs.w3pla.net/autokiller/kernel
http://forum.xda-developers.com/showthread.php?t=813309
http://forum.xda-developers.com/showpost.php?p=11496754
http://forum.xda-developers.com/showthread.php?t=991276
Quite obviously this is not kifno's "original" work or ideas, or even code. After all it was recently noted in here that there is code for GSM devices. Why would that be in a script for a CDMA phone, unless of course the code was kanged. I just wish that if work was to be shared, it ought to be done so properly and not with this "MY WORK THIS TIME I SWEAR SILLY" bull.
I sent kifno a PM earlier tonight about this VERY thread when the OP only had credited uncorrupted. I told him to fix the lies about "all mine" and he did somewhat, but not fully as you all can see. My point is that this kind of action on my part SHOULD be unnecessary, but it seems to continue to be in ALL the threads kifno makes. Users, I know lots of this works but that's not the point. It is taken, and unabashedly handed out as original work, which it is not. That is why I continue to post relevant info when it it obvious. It is NOT to incite war, only to pay respect to the actual devs who created these works, which kifno does not seem to want to do.
I'm Pretty sure that the definition of kanging is taking others work without askance or credit - which is what this is. It's actually OK and encouraged to use others work in this community, that way we all get better tweaks and a better knowledge and a better user experience. BUT this is only OK if done following forum rules - which stem from mutual respect and community enrichment.
I am convinced the response will be "BUT BUT I DIDN'T COPY, I MADE THESE MYSELF", to which my response would be "yeah right".
Have a beautiful night/day ladies and gents. I have said my piece...
Let's try to stick to constructive criticism and not resort to personal attacks. It's killing the forum.
il Duce said:
I feel like I am on a creepy merry-go-round.....
Yet again kifno, when you could be an asset to the community simply by giving proper credits originally and saying that you used others work and made it better, you take all or most of the credit for yourself. If you want to help the community, do so by following the rules and common sense. FYI you cant "improve" brainmasters sd tweak because ALL it does is change the read_ahead_kb in sys/devices/virtual/bdi/179:0/read_ahead_kb. Now here's some links that users/mods/kifno would do well to pay attention to the dates of, these are also the only ones that I personally have reviewed recently, I would bet there are more:
http://andrs.w3pla.net/autokiller/kernel
http://forum.xda-developers.com/showthread.php?t=813309
http://forum.xda-developers.com/showpost.php?p=11496754
http://forum.xda-developers.com/showthread.php?t=991276
Quite obviously this is not kifno's "original" work or ideas, or even code. After all it was recently noted in here that there is code for GSM devices. Why would that be in a script for a CDMA phone, unless of course the code was kanged. I just wish that if work was to be shared, it ought to be done so properly and not with this "MY WORK THIS TIME I SWEAR SILLY" bull.
I sent kifno a PM earlier tonight about this VERY thread when the OP only had credited uncorrupted. I told him to fix the lies about "all mine" and he did somewhat, but not fully as you all can see. My point is that this kind of action on my part SHOULD be unnecessary, but it seems to continue to be in ALL the threads kifno makes. Users, I know lots of this works but that's not the point. It is taken, and unabashedly handed out as original work, which it is not. That is why I continue to post relevant info when it it obvious. It is NOT to incite war, only to pay respect to the actual devs who created these works, which kifno does not seem to want to do.
I'm Pretty sure that the definition of kanging is taking others work without askance or credit - which is what this is. It's actually OK and encouraged to use others work in this community, that way we all get better tweaks and a better knowledge and a better user experience. BUT this is only OK if done following forum rules - which stem from mutual respect and community enrichment.
I am convinced the response will be "BUT BUT I DIDN'T COPY, I MADE THESE MYSELF", to which my response would be "yeah right".
Have a beautiful night/day ladies and gents. I have said my piece...
Click to expand...
Click to collapse
After reading this, i agree with u. Kifno should credit more people for most of the things on here. All he did was compile it all together. Am i saying that right?
Ok flash on the sense rom didn't really do so well phone froze 3 times on the market took battery out then froze on whit HTC screen so I tried it cm7.2 and works like a charm
Sent from my HERO200 using XDA App
kifno said:
No it doesn't remove this I need to make a removal .zip asap. But You can just take the 768mhz zip and upzip it and change the cpu values in the /system/bin/kifCPU.sh file
just look for the the lines that effect the cpu speeds. If you don't know which ones do, then read my explanation for my tweaks
OH YEAH EVERYONE I ADDED MY EXPLANATION FOR TWEAKS If I am wrong about anything please, tell me asap so I can update it so people don't learn false information.
Glad to be on a fresh start with this
Click to expand...
Click to collapse
Humm well didn't really wanna go that far into your script. Is there anyway if you have some time free you could possibly edit the 768 scripts for me and post or send them threw pm??? I wouldn't mine running your mods and posting feed back I just don't want to change my daily kernel. Ill hold off on flashing this untill I hear from you. Thanks.
#Root/Hack-Mod_Always*
bravo1565 said:
Ok flash on the sense rom didn't really do so well phone froze 3 times on the market took battery out then froze on whit HTC screen so I tried it cm7.2 and works like a charm
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
Do you use kifnos sense rom or espresso? I flashed the latency 768 tweak on his espresso 2.1 rom and everythings running flawlessly. I flashed the tweak on a full battery so I'll be back when the phone dies to report my battery life and performance.
jasonmaloney said:
In regard to your explanation:
Code:
/sys/block/mmcblk1/queue/nr_requests
As stated previously in the old thread, this file has never and will never exist on the hero, because we only have one SD device.
Click to expand...
Click to collapse
So we don't have the the mmcblck1 partition? Hmp I know what I'll do to fix m y nr_request tweak then I'll add it to the loop that checks for all values in the mmc* blocks Checked it and it already is I need to edit my reasons for the tweaks lol. So no worries this value is only changed in all mmc blocks that exsist.
jasonmaloney said:
0.0.0.0 is NOT a DNS. All this value does is force the phone to use whichever DNS the network specifies (which it may or may not be doing anyway).
Code:
ro.ril.hsxpa=2
ro.ril.gprsclass=8
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=24
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=3
You said to "ask someone in the networking field" about these values. Someone from the "networking field" (dhero) already chimed in (as did several other people) and told you that some of these lines don't even do anything. The only thing here that's probably making a difference in network speeds is the bitmask value (which is just setting all bits to 1, negating what they actually do).
For instance, I can tell you 100%, for a fact, that the "ro.ril.enable.dtm" line does nothing on the hero, because the entire point of this line is to enable simultaneous use of voice/data on GSM networks. CDMA networks have never been able to do this, and that's not something you can change.
The line "ro.ril.enable.a53" also does absolutely nothing on our phones. A5/3 is an encryption algorithm, used on GSM networks. It has no use in CDMA devices, and was actually broken by hackers in recent history.
Click to expand...
Click to collapse
Oh wee thanks jason The lines you said to remove, and a few more lines have been removed from the network tweak, for next release, because only a few are making the real difference which I have tested.
jasonmaloney said:
I've love to see some real documentation of how setting these values really makes a difference. The facts of speed tests are that (1) they are only testing your "burst" speeds which means they don't really answer many questions about long-term performance and that (2) they can vary wildly in the same time frame. I know that I have personally always had better EV-DO speeds than your scripts supposedly provide (sustained average 1.5-2mb/s downstream), and that all depends on signal range and nearby devices.
Right now I'm working on actually reverse-engineering the HTC RIL library to see what these values REALLY change. As far as I can tell, some of them never actually make a difference on the CDMA Hero and are just left over from the GSM Hero and other devices. They are read in from the prop file, but the variables which contain them aren't referenced by the CDMA code paths.
Click to expand...
Click to collapse
If you could figure out exactly what they change (as far as I know its just general speed) that would be better for the first post's explanation of them. I'm going based of the fact that when I changed a few of the strings values, it slowed the network down, and certain values speed it up.
jasonmaloney said:
Code:
windowsmgr.max_events_per_sec=60
As stated previously in the old thread, this value does nothing because that's already the default value in the source code.
Code:
keyguard.no_require_sim=true
As stated previously in the old thread, this is already set in the build props.
Click to expand...
Click to collapse
Both removed already last night
jasonmaloney said:
Code:
debug.sf.hw=1
As stated previously in the old thread (and backed up by PROVIDING THE SOURCE CODE), this line does nothing because it's the equivalent of not specifying it at all. This is why we removed it from the CM build a LONG time ago. The ONLY time this line would EVER make a difference is if someone had deliberately set it to 0 beforehand, and as far as I know, no ROM (including the stock one) has ever shipped with 0 set.
The DEFAULT behavior of SurfaceFlinger is to always use the GPU when possible. The ONLY reason the "debug.sf.hw" line exists is for troubleshooting/debugging, for example when booting the emulator.
Click to expand...
Click to collapse
This is one that wasn't removed last night but will be I didn't know that it wasn't set to 0 because it wasn't specified in any roms I looked at. Thanks for that info
jasonmaloney said:
In regard to my own exploration of the zips provided (for reference I used the no-latency 691 zip):
You have a typo in your code.
Code:
CHECK_NOOP=` cat /sys/block/mtdblock3/queue/scheduler
The tailing backtick is missing.
Click to expand...
Click to collapse
I hate making those minor mistakes thanks for catching that jason
jasonmaloney said:
Why are you providing busybox in your zip? The version you provide (1.15) is outdated; a newer version is already in CM7 and other ROM images. And the folder you're copying it to (system/sbin) doesn't actually exist.
Click to expand...
Click to collapse
From what uncorrupted told me, in a way it is better than the busybox in most roms. I'll ask him about it, but until he provides reasons why, I'll remove it.
jasonmaloney said:
By overwriting the init.local.rc script instead of appending your code to it, you are effectively breaking compcache in CM.
Click to expand...
Click to collapse
Saw that myself when I looked at CM7's init.local.rc. It breaks that and any other service set in the init.local.rc. WHICH IS NOT GOOD.
jasonmaloney said:
Your CPU profiles contain multiple infinite loops. This is bad practice. Your loops don't contain ANY sleep calls as far as I can tell, which means they run indefinitely, sucking up CPU cycles and battery. Your script should be sleeping on an interval.
Click to expand...
Click to collapse
I'll have it sleep every second or so because I doubt anyone is running their phone straight for hours and hours without letting it sleep. So adding a sleep interval will help with the should help with the battery life portion of this tweak as well
I had a sleep interval back in the v1.x series which helped the battery life, in my other infinite scripts, I need to add that again
jasonmaloney said:
The functions called by your infinite loop themselves contain infinite loops, which means that (as far as I can tell) they will never return and charging source changes will never be detected. Am I reading this wrong? Does this really work?
Click to expand...
Click to collapse
Oh yes Do you know what a until loop is? It basically saying the temperature drops it will cap the cpu speed. Once the temperature isn't high anymore then it uncaps the cpu speed again So this is to keep your phone from getting too hot, I know my phone does Also since the cpu is being capped this would result in the battery temperature going down and therefore once the temp is lowered it returns to the battery charging source changes. So yes it does work
il Duce said:
I feel like I am on a creepy merry-go-round.....
Yet again kifno, when you could be an asset to the community simply by giving proper credits originally and saying that you used others work and made it better, you take all or most of the credit for yourself. If you want to help the community, do so by following the rules and common sense. FYI you cant "improve" brainmasters sd tweak because ALL it does is change the read_ahead_kb in sys/devices/virtual/bdi/179:0/read_ahead_kb.
Click to expand...
Click to collapse
I did improve his tweak, so there you are wrong sir. I will be sending him a message about if he changed the value for all the bdi's sub-directories read_ahead_kb he would in fact improve his sd tweak. He sets it for just the 179:0 but when I changed it to set it for changing all the bdi's sub-directories read_ahead_kb my sd card performance was much better, than just his tweak which just made it better.
il Duce said:
Now here's some links that users/mods/kifno would do well to pay attention to the dates of, these are also the only ones that I personally have reviewed recently, I would bet there are more:
http://andrs.w3pla.net/autokiller/kernel
http://forum.xda-developers.com/showthread.php?t=813309
http://forum.xda-developers.com/showpost.php?p=11496754
http://forum.xda-developers.com/showthread.php?t=991276
Click to expand...
Click to collapse
The one's who I ORIGIANALLY got the ideas from are credited. Anyone who is not credited I did not get any ideas from. If a person isn't allowed to use their knowledge of linux operating system's files and how they tweak linux and use them on android then that just isn't right. I've been on linux for years and you're saying that the tweaks I used for my linux system I can't change the values and use on the heroc, come on now. That isn't fair.
il Duce said:
Quite obviously this is not kifno's "original" work or ideas, or even code. After all it was recently noted in here that there is code for GSM devices. Why would that be in a script for a CDMA phone, unless of course the code was kanged. I just wish that if work was to be shared, it ought to be done so properly and not with this "MY WORK THIS TIME I SWEAR SILLY" bull.
I sent kifno a PM earlier tonight about this VERY thread when the OP only had credited uncorrupted. I told him to fix the lies about "all mine" and he did somewhat, but not fully as you all can see. My point is that this kind of action on my part SHOULD be unnecessary, but it seems to continue to be in ALL the threads kifno makes. Users, I know lots of this works but that's not the point. It is taken, and unabashedly handed out as original work, which it is not. That is why I continue to post relevant info when it it obvious. It is NOT to incite war, only to pay respect to the actual devs who created these works, which kifno does not seem to want to do.
I'm Pretty sure that the definition of kanging is taking others work without askance or credit - which is what this is. It's actually OK and encouraged to use others work in this community, that way we all get better tweaks and a better knowledge and a better user experience. BUT this is only OK if done following forum rules - which stem from mutual respect and community enrichment.
I am convinced the response will be "BUT BUT I DIDN'T COPY, I MADE THESE MYSELF", to which my response would be "yeah right".
Have a beautiful night/day ladies and gents. I have said my piece...
Click to expand...
Click to collapse
The response you are "convinced" will be, is not the response I am giving you. The people whose ideas I were using and made better were back from the 0.x series (which is long ago). Also as for the code not even being mine? THE MAJORITY OF IT IS MINE. I used the screen state idea and built off of it to make a full out, cpu/batter tweak utility replacement. My next step is to make a menu for the users to change those values themselves. The users whose ideas I have used AND IMPROVED ON, have been credited as we talked about, I just had to backtrack who I really got the ideas from and not others who used their ideas as well as myself. Everything else I have done, and came up with myself. Believe it or not. Use linux for a few years on a sucky laptop and I bet you'll be wanted to tweak it, too. Which is how I learned so much about linux's files, which I quickly found android to be almost like a "portable linux" operating system One of the reasons I got the phone. Have a beautiful day ladies and gents
"kif'd"
- Kifno
XGodOfModzX said:
After reading this, i agree with u. Kifno should credit more people for most of the things on here. All he did was compile it all together. Am i saying that right?
Click to expand...
Click to collapse
Read my post, i used IDEAS and made them better. The one thing I did use and compile into the tweak was the network build.prop tweaks. Which some of the strings do nothing. Be on the look out for v2.0.1 also the credits that are there now are for v2.0.1 which will be released tonight. Minor changes made but they're for the better.
AerialX said:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default... I decided on the "slow" version - 8bdefb7e - as it's the most compatible option. The "fast" version can be chosen as a preference for those who prefer the speed. It may not work on all devices, and seems to produce artifacts and some tearing, though it probably is preferable for most simply due to the speed.
So, here you go, latest version: Download
Built for ARM and ARMv7, does not include the NEON extensions. You may want to uninstall the old one before installing this.
EDIT: Fine, have a NEON build too: Download
Hint: the main change is the inclusion of settings. I consider this build to be very close to the initial release for the application on the Android Market. Just a few things remain...
What's Left
In order of priority...
Filtering of non-white-screen presets. The app will include the projectM preset library by default, excluding any that just result in a white screen. I don't believe I will be able to distribute any of the Winamp/MilkDrop library itself, as awesome as it is.
Stability enhancements. It's probably still somewhat crashy. I'm not sure how much, though. I'd love to get some detailed reports on how stable/crashy it is for you guys.
snoop() support, otherwise the wallpaper requires 2.3... I don't have anything older though. Would anyone be able to test on an older OS for me if I supplied a build?
x86 support. Means writing a few missing STL pieces.
NEON detection, and the loading of an appropriate optimized library. I get the feeling that this is just a placebo, but will try to get it in.
Optimizations. Would be nice if it didn't essentially restart every time you visit your home screen. I'm probably leaving this for a 1.1 release though.
Localizations. If anyone wants to help translate the settings page into their native tongue, I'll happily include them.
Anything else I forgot...
What I Need
It would be great if anyone who tries it can comment on its stability. Whether it often dies, reverts to some other wallpaper, completely kills your system, or whatever. Just give me your overall experience with the wallpaper. I'm not necessarily interested in hearing about its performance at this point - if it runs slowly on your phone, I suggest switching to the "fast" render method and only using presets that run speedily. Of course, miscellaneous suggestions / comments / criticism are welcome as well!
Another thing I was hoping someone could do is go through all the presets and filter out the bad "white" ones. The new settings page makes it easy to test a single preset at will. So if anyone is willing to do this, I could really use two zips: one containing all working presets from the projectM set, one containing all from the MilkDrop set.
As a base for the projectM set, please use this: Download
For the base MilkDrop set, find the attachment from a few pages ago.
You may also want to note any that run particularly slow, but please don't exclude them from these packages.
EDIT: As a test, feel free to try the exact same preset on both the non-NEON and NEON builds and see if there's any noticeable improvement there.
Click to expand...
Click to collapse
Hands down best app ever
Sent from my LG-P999 using XDA App
Any screenshots?
Um seems to be a few post missing in this thread... Usually when something starts like this:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default...
Click to expand...
Click to collapse
What results are we talking about here? What is this exactly? Kinda like writing a book that starts:
But when the baby came out looking like death on a hot tin roof, Jim finally found the nerve to call her out and say, "Devil wench, I will not accept that thing as my my spawn! I know you have been sleeping with your brother!"
Well sadly i don't have an answer for that question yet...
I'm trying to think of a way to put KSM to the test on my android device.
As far as i understand it is possible that the kernel actually causes high CPU usage trying to map and unmap memory pages over and over again.
This issue is known for linux and other virtual machines so it is possible that the Same effect will be on the android vm
Testings that i found are not relevant to android.
For example:
The result is a dramatic decrease in memory usage in virtualization environments. In a virtualization server, Red Hat found that thanks to KSM, KVM can run as many as 52 Windows XP VMs with 1 GB of RAM each on a server with just 16 GB of RAM. Because KSM works transparently to userspace apps, it can be adopted very easily, and provides huge memory savings for free to current production systems. It was originally developed for use with KVM, but it can be also used with any other virtualization system - or even in non virtualization workloads, for example applications that for some reason have several processes using lots of memory that could be shared.
Click to expand...
Click to collapse
http://kernelnewbies.org/Linux_2_6_32
What i would really want to know is what would happen if each of these VMs Would run a different application/game/audio/graphics software at the same time ? or what if the same vm will run many different apps ? and also to compare cpu usage with and without KSM
Guess i'll need a tool for that. something like 'iostat' but for memory diagnostic and another tool to see a per process CPU usage but 'top' is not good enough for that.
Any way, the best test should present clear results with precised data.
I'll keep looking for legit way to put it to the test.
If you can think of a way to test KSM with android, please let me know.
This is a technique that relates mostly to processes like virtualisation. For example, when you load 5 windows XP VMs, you'll have a good 10 - 20 services that are practically the same in memory in each VM. Instead of each service using 10mb (ie, 10mb x 5 = 50mb), you only need say 15 or 20mb using KSM. If you use different applications, it is very unlikely that anything would be saved FOR THAT APPLICATION. However, the main elements of a Windows XP System would still be there (drivers, explorer, firewall, logon, search and so on). Means little in one setup, but when you have several VMs it is shown to be a huge advantage. As we know a simple XP install can use 500mb of RAM actively, and this is fairly uniform across instals.
With android, i don't know if there are specific RAM savings to be had. Don't know enough about the inner workings and the sandbox android puts its apps in or how apps interact with system services. Sadly, i can't think of a good way to test it out either, but i'll be keeping an eye on this topic for someone (much) more knowledgeable to come along.
Harbb said:
Sadly, i can't think of a good way to test it out either, but i'll be keeping an eye on this topic for someone (much) more knowledgeable to come along.
Click to expand...
Click to collapse
Enter bedalus, stands there with a vacant expression on his face. Harbb looks disappointed.
kernels ; battery ; ROM ; gov/sched
That entire paragraph was dedicated to you bedalus, we both know that.
Lol
I hope someone can answer this though.
kernels ; battery ; ROM ; gov/sched
Wait for someone............
Sent from my Nexus S using xda premium
KSM does not improve performance on Android just like that - all enabling KSM does, is enable SUPPORT for the Feature but Applications would have to make use of the feature, which they don't.
You can easily verify this like that :
echo 1 > /sys/kernel/mm/ksm/run
<wait and/or run the Applications of your choice>
cat /sys/kernel/mm/ksm/pages_sharing
IF the above shows a value > 0 then you are making use of KSM else it's just available, without anyone using the feature.
Here's an interesting Article that gives a little more insight :
http://www.linux-kvm.com/content/using-ksm-kernel-samepage-merging-kvm
By the way, the same is true for ZCACHE. If you really want to make better use of your Memory (RAM) then using ZRAM as a Swapdevice does work (and may often make sense, too).
That all said : There appear to be efforts to make use of KSM http://forum.xda-developers.com/showthread.php?t=1464758 - so things may well change ...
any update on this...?
Again since Sensation XE doesn't have people promoting seeder too much, I brought it here for those who are not familiar with this.
Please don't post negative things here. I only understand theory of this mod that's all. And I held no credit to any of the content.
Requirements:
1. S-Off
2. Custom recovery
3. Rooted
4. Init.d Support for flashable version
CREDITS FIRST:
lambgx02 (for the original seeder and APK format) http://forum.xda-developers.com/showthread.php?t=1987032
ryuinferno (for flashable version) http://forum.xda-developers.com/showpost.php?p=36479461&postcount=1924
FAQ:
What is seeder?
Its a mod that increases resource in your device so it wont suffer any starvation(lag).
Above is the easiest way to explain it.
What is the difference between APK and Flashable version?
APK version provides more options to tune method it provides resource and the frequency of it.
Flashable version will be automated in your device as long as your device have init.d support.
How can you prove it significantly improves performance?
Well I can't really tell, Dev's in sensation department is extremely good all ROM's are well tweaked. Its good enough without it, but IMHO it will be better with it.
To .zip version user only
Once you flashed it. Go to terminal emulator. Enter
su
seeder
A menu will show up. It will indicate if seeder is working in your device or not.
Thank the developers of this awesome invention, then Thank me if you think its good for me to bring it here.
Cheers!
TIP: Try on those high load games, the loading speed improvements are the best ways I can see after using this.
good
downloaded the app using the QR code and never installed. wheb you select it tin the task bar it doesnt go into the instalation menu. however when i went to the downloads in my phone it opened the installer. it tried too install but took a very long time. but in the end worked thansk made a slight difference to the lag on my phone. :good:
HTC sensation 4G
ROM: CM 10.1-20130212-albinoman887-pyramid
Although this improves performance slightly, the only thing it really does is run your CPU at a higher frequency. This'll cost precious battery life.
ridder215215 said:
Although this improves performance slightly, the only thing it really does is run your CPU at a higher frequency. This'll cost precious battery life.
Click to expand...
Click to collapse
Can't say you're wrong at the battery life part. But IMHO, it doesn't actually touches the frequency part. Frequency is something that runs instructions, but this thing provides additional resource aka fuel for your device. It don't make your engine combust quicker, it will only make your engine combust cleaner, and more fuel that's all.
KiD3991 said:
Can't say you're wrong at the battery life part. But IMHO, it doesn't actually touches the frequency part. Frequency is something that runs instructions, but this thing provides additional resource aka fuel for your device. It don't make your engine combust quicker, it will only make your engine combust cleaner, and more fuel that's all.
Click to expand...
Click to collapse
I'm just going to leave this quote from a CM maintainer here:
“IMNSHO the recent entropy pool fad is bull***. The only users of /dev/random are libcrypto (used for cryptographic operations like SSL connections, ssh key generation, and so on), wpa_supplicant/hostapd (to generate WEP/WPA keys while in AP mode), and the libraries that generate random partition IDs when you do an ext2/3/4 format. None of those 3 users are in the path of app execution, so feeding random from urandom does nothing except make random… well… less random.
The only conceivable reason some devices may feel faster is because by constantly polling the PRNG, it keeps the device’s I/O in constant use (which in turn, depending on device, will make the CPU stick to higher clock frequencies to keep up and/or ramp up the IO scheduler).”
Source
Don't get me wrong, if it seems to help for you, that's great. But I'm not going to use it.
ridder215215 said:
I'm just going to leave this quote from a CM maintainer here:
“IMNSHO the recent entropy pool fad is bull***. The only users of /dev/random are libcrypto (used for cryptographic operations like SSL connections, ssh key generation, and so on), wpa_supplicant/hostapd (to generate WEP/WPA keys while in AP mode), and the libraries that generate random partition IDs when you do an ext2/3/4 format. None of those 3 users are in the path of app execution, so feeding random from urandom does nothing except make random… well… less random.
The only conceivable reason some devices may feel faster is because by constantly polling the PRNG, it keeps the device’s I/O in constant use (which in turn, depending on device, will make the CPU stick to higher clock frequencies to keep up and/or ramp up the IO scheduler).”
Source
Don't get me wrong, if it seems to help for you, that's great. But I'm not going to use it.
Click to expand...
Click to collapse
I promoted this because it seemed great on my previous device. But in sensation the effect is much lesser than anticipated. Works in my friend's S2 though. Maybe its for low end devices only tsk tsk tsk.
But still, no harm experimenting on everything.
KiD3991 said:
I promoted this because it seemed great on my previous device. But in sensation the effect is much lesser than anticipated. Works in my friend's S2 though. Maybe its for low end devices only tsk tsk tsk.
But still, no harm experimenting on everything.
Click to expand...
Click to collapse
Seeder was designed for older versions of android. It is stated in the thread that it is solved in newer versions of android.