So with all the excitement going on in the page pool thread I was doing some external reading. One topic that caught my interest is NAND and NOR ROM.
I got a nice summary from here:
http://blogs.msdn.com/windowsmobile/archive/2005/08/19/453784.aspx
Basically, the synopsis is:
NOR: Faster to read, slower to write.
NAND: Slower to read, faster to write.
But, more importantly, NOR ROM let's you perform XIP operations. Now i remember seeing this XIP acronym before...in a directory when I extracted a ROM. This leads me to believe that at least part of the ROM in the Kaiser is NOR ROM.
XIP means eXecute In Place. It basically allows code to be executed directly from the ROM without first being copied into the RAM. This means less RAM utilization. As the article states i works for programs only, not user data files.
If we look in the XIP directory of an extracted ROM we see subdirectories like:
busenum.dll
diskcache.dll
imgfs.dll
These are things like low level bus, disk, and file system drivers. These things make perfect sense to XIP.
My question then is... if indeed we do have NOR ROM that can do XIP operations, how much is free on a typical ROM? AND can we cook in other applications into this XIP NOR location instead of into the NAND ROM and thus have those eXecute in Place and free up additional RAM?
It would be nice to get the 3% of my RAM back from Voice Command, or the 1% from PocketCM, etc, etc...
Could it be as easy as moving .dll files from \SYS to \ROM\XIP before cooking the ROM? I doubt it, but is it possible?
I'm just throwing a concept out there and asking about it's feasability. I'm not really a developer so I don't know how much further I can take this.
Thoughts?
bengalih said:
My question then is... if indeed we do have NOR ROM that can do XIP operations, how much is free on a typical ROM? AND can we cook in other applications into this XIP NOR location instead of into the NAND ROM and thus have those eXecute in Place and free up additional RAM?
It would be nice to get the 3% of my RAM back from Voice Command, or the 1% from PocketCM, etc, etc...
Could it be as easy as moving .dll files from \SYS to \ROM\XIP before cooking the ROM? I doubt it, but is it possible?
I'm just throwing a concept out there and asking about it's feasability. I'm not really a developer so I don't know how much further I can take this.
Click to expand...
Click to collapse
I don't think that blog applies to the Kaiser-like devices anymore. We already use all the ROM space we get. The partitioning between XIP and storage is out of the same space and controlled by how the ROM image is built and whatever they set the pagepool to.
Did you run out of space of the 100MB+ internal storage we all get?
I don't know why it wouldn't apply...it's not a WM5 vs WM6 issue.
Based on the only specs I have seen it lists the Kaiser with 256 ROM and 128 RAM.
The question is what type of ROM is it? Devices can mix NOR and NAND ROM. And based on what I see on the extracted ROM, at least some of it must be NOR (because of the existence of the XIP directories).
And this isn't a question of storage space. I am not trying to get more usable storage...I have a 8GB SDHC card for that. I am trying to maximize my available application space.
The point of my post is... can an application, let's say like Voice Command be moved from what might be the NAND portion of the ROM into the NOR portion of the RAM (from \SYS to \ROM\XIP). It would take up the same space of the TOTAL ROM, but when it executed it DOES NOT NEED BE LOADED INTO RAM and thus your available application space is not decreased.
Again, I am not a developer, so I may be way off in asking if this can be done. However your response is one that doesn't speak to the theory I am proposing.
if I remember right this was talked about before but on a different device I think the hermes. I am not sure of the reason it couldnt be done but I just remember it couldnt lol. Something about allocated memory maps
Some interesting things
I found this wile reading the link you posted. Some great information in there.
By the way, every SD and CF card is made out of NAND flash. So, no, you can't XIP programs stored on a storage card.
Click to expand...
Click to collapse
So am I reading this right. That any program we have stored on our Storage Card won't utilize the XIP
I've been working on & subsequently screwing up, page pool alteraitions for awhile. Because I'm messing with a Kaiser(CE5) & a UMPC (CE6) based device, I can tell you that while the pagepool will save you some seconds, mostly with the loading of contacts, your inbox, & the boot to os speed of the device, for the most part you're right, you won't see much difference.
However, with CE6, that will change. With CE 6 based devices you will be able to completely comtrol paging, be it XIP or Data (Read Only) paging. Maybe wm7 will introduce CE6 to PDA devices. With CE6, formerly & frequently confused with WM6, you will have 2 page pools & several controls over them including compaction.
The effectiveness of page pool sizes can vary widely depending on the types of processes & programs you use, but suffice to say, the average user will take little to no benefit from a larger paging file.
For all of you truly interested, there is a PB process file called DevHealth.exe, that can be used via SD card to report the actual status of the paging pool. Google it, you will find it. Kind of interesting to see what your device is actually doing before & after the changes.
AllTheWay said:
I found this wile reading the link you posted. Some great information in there.
So am I reading this right. That any program we have stored on our Storage Card won't utilize the XIP
Click to expand...
Click to collapse
No but what the OP is asking is if we can take apps and put them in the XIP section and run them from there. I think someone should try it out just cook up a rom with a complete app cooked in the XIP and see what happens. the worst is bad blocks i would guess but maybe POF or OLI should chime in on this one.
I do believe you can XIP from an SD card, I believe MS has done this with a few test devices that utilize under battery sd cards. I think it's not something they've done mostly because of problems in system stability when the SD is removed.
austinsnyc said:
No but what the OP is asking is if we can take apps and put them in the XIP section and run them from there. I think someone should try it out just cook up a rom with a complete app cooked in the XIP and see what happens. the worst is bad blocks i would guess but maybe POF or OLI should chime in on this one.
Click to expand...
Click to collapse
THANK YOU AUSTIN!
Yes, this is what I am saying. Forget about SD cards (which, according to what I have read are all NAND and thus can't XIP).
I am just asking if some of the applications that we are cooking into the flash (the things that extract to \SYS) like MS Voice Command, CM Contacts, QuickGPS, etc... if instead those things can be places in XIP.
Again, this is under the assumption (which is a big assumption) that what is in \XIP gets placed in the NOR ROM and what is in \SYS gets placed in the NAND.
What this would mean is that when you execute any of the programs I mention, like say Quick GPS you won't see the RAM utilization on your device go up, meaning you will have the same amount of available free memory. This is because of the XIP (based on the description I have read) it can be executed from the ROM without being copied into RAM.
Now, my guess is that even though the NOR has faster reads than NAND, it still might be slower than RAM. So, it might take another second to open Quick GPS. However for some apps I think I would prefer the slight delay in order for my available memory to be increased.
GSLEON3 said:
I've been working on & subsequently screwing up, page pool alteraitions for awhile. Because I'm messing with a Kaiser(CE5) & a UMPC (CE6) based device, I can tell you that while the pagepool will save you some seconds, mostly with the loading of contacts, your inbox, & the boot to os speed of the device, for the most part you're right, you won't see much difference....
For all of you truly interested, there is a PB process file called DevHealth.exe, that can be used via SD card to report the actual status of the paging pool. Google it, you will find it. Kind of interesting to see what your device is actually doing before & after the changes.
Click to expand...
Click to collapse
Good info Leon...but better to put this in the pagepool thread so we can discuss it there (and please do). What I'm trying to get at here is not directly related to pagepool sizes and speeds.
austinsnyc said:
if I remember right this was talked about before but on a different device I think the hermes. I am not sure of the reason it couldnt be done but I just remember it couldnt lol. Something about allocated memory maps
Click to expand...
Click to collapse
That's entirely possible. Again, I'm being the "idea guy" as I'm trying to synthesize some info I have absorbed. The most programming I do is high level scripting and VB so I don't know details about how this stuff would actually work down at the memory map level. There may be some other issues as well. I was hoping there was someone in these forums who actually had the knowledge (and wasn't just following cooking tutorials like most of us) of how this stuff truly interacts.
Also please reference my post in the pagepool thread, has some good thoughts (I think!):
http://forum.xda-developers.com/showpost.php?p=2101324&postcount=99
bengalih said:
http://forum.xda-developers.com/showpost.php?p=2101324&postcount=99
Click to expand...
Click to collapse
In addition to the above, I have found some more info which may partially defeat my reasoning:
XIPKernel
There are portions of the deepest parts of the OS that have to XIP. If you're on NOR, that code just XIPs like everything else. Not so on NAND. For a NAND system to boot, it needs to load this code into RAM first and then run it from there. When the system is running, it can't really tell if it's running from RAM or ROM, so it assumes it's running from ROM and doesn't count this space.
The XIPKernel region tends to be between 1.5 and 2M.
Click to expand...
Click to collapse
So it seems that just because we have a \XIP directory doesn't mean we have NOR ROM. It could just be the area the ROM places data that in NEEDS to XIP, and therefore means that it will get copied to RAM on boot (instead of just XIPing from where it is in ROM). This could also account for the additional "missing" RAM up to 128MB.
Therefore moving an application to this \XIP pre-cook doesn't mean that it will save us any RAM (again, assuming we DON'T have NOR ROM). It could however speed up that application since we are basically "pre-loading" it into RAM instead of waiting for the load to be user initiated.
I guess a question now is does all XIPed code run at the same time and is that all at boot? It does us no good to try and load up voice command (or QuickGPS, etc.) before the supporting code from the OS has loaded.
So, this may all be a wash, but it does help explain some of the interaction better and even if it leads no where, at least we will better understand how the devices memory system works.
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.