hello,
i been testing some options, to speed up our sensation.
i had great results on android 2.3.4 (sense 3.0)
not so great on android 2.3.5, on bench tests, but on UI i cant tell the difference.
if you can improve this, be my guest
opinions are welcome
GOOD PERFORMANCE AND GOOD BATTERY LIFE
Code:
#!/system/bin/sh
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
echo 5 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo 100000 > /proc/sys/kernel/sched_rt_period_us
echo 95000 > /proc/sys/kernel/sched_rt_runtime_us
echo 0 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/dirty_ratio
echo 4 > /proc/sys/vm/dirty_background_ratio
echo 4096 > /proc/sys/vm/min_free_kbytes
echo 5 > /proc/sys/vm/vfs_cache_pressure
echo 0 > /proc/sys/vm/oom_kill_allocating_task
echo 0 > /proc/sys/vm/laptop_mode
echo 0 > /proc/sys/vm/panic_on_oom
echo 0 > /proc/sys/kernel/tainted
echo 3 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/page-cluster
echo 10 > /proc/sys/fs/lease-break-time
echo 1 > /proc/sys/vm/overcommit_memory
echo 100 > /proc/sys/vm/overcommit_ratio
echo 500 > /proc/sys/vm/dirty_expire_centisecs
echo 1000 > /proc/sys/vm/dirty_writeback_centisecs
echo 10000000 > /proc/sys/kernel/sched_latency_ns
echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns
echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns
echo 725000 > /proc/sys/kernel/sched_shares_ratelimit
MAXIMUM PERFORMANCE
Code:
#!/system/bin/sh
echo 20000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
echo 60 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
echo 5 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo 100000 > /proc/sys/kernel/sched_rt_period_us
echo 95000 > /proc/sys/kernel/sched_rt_runtime_us
echo 0 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/dirty_ratio
echo 4 > /proc/sys/vm/dirty_background_ratio
echo 4096 > /proc/sys/vm/min_free_kbytes
echo 5 > /proc/sys/vm/vfs_cache_pressure
echo 0 > /proc/sys/vm/oom_kill_allocating_task
echo 0 > /proc/sys/vm/laptop_mode
echo 0 > /proc/sys/vm/panic_on_oom
echo 0 > /proc/sys/kernel/tainted
echo 3 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/page-cluster
echo 10 > /proc/sys/fs/lease-break-time
echo 1 > /proc/sys/vm/overcommit_memory
echo 100 > /proc/sys/vm/overcommit_ratio
echo 200 > /proc/sys/vm/dirty_expire_centisecs
echo 500 > /proc/sys/vm/dirty_writeback_centisecs
echo 10000000 > /proc/sys/kernel/sched_latency_ns
echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns
echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns
echo 725000 > /proc/sys/kernel/sched_shares_ratelimit
EDIT:14-10-2011
added "echo 10 > /proc/sys/fs/lease-break-time"
EDIT:08-10-2011
change "echo 1000000 > /proc/sys/kernel/sched_latency_ns" to "echo 10000000 > /proc/sys/kernel/sched_latency_ns"
change "echo 100000 > /proc/sys/kernel/sched_min_granularity_ns" to "echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns"
MAN
Code:
[SIZE="3"][U]sampling_down_factor[/U]:
this parameter controls the rate at which the
kernel makes a decision on when to decrease the frequency while running
at top speed. When set to 1 (the default) decisions to reevaluate load
are made at the same interval regardless of current clock speed. But
when set to greater than 1 (e.g. 100) it acts as a multiplier for the
scheduling interval for reevaluating load when the CPU is at its top
speed due to high load. This improves performance by reducing the overhead
of load evaluation and helping the CPU stay at its top speed when truly
busy, rather than shifting back and forth in speed. This tunable has no
effect on behavior at lower speeds/lower CPU loads.
sampling_down_factor merge time
1 (default) 1 minute and 59 seconds.
20 1 minute and 47 seconds.
100 1 minute and 29 seconds.
150 1 minute and 24 seconds.
200 1 minute and 22 seconds.
300 1 minute and 20 seconds.
500 1 minute and 12 seconds.
1500 1 minute and 7 seconds.[/SIZE]
Code:
[SIZE="3"]
[U]swappiness[/U]:
parameter controls the tendency of the kernel to move processes out of
hysical memory and onto the swap disk. Because disks are much slower than
RAM, this can lead to slower response times for system and applications if
rocesses are too aggressively moved out of memory.
swappiness can have a value of between 0 and 100
swappiness=0 tells the kernel to avoid swapping processes out of physical
memory for as long as possible
swappiness=100 tells the kernel to aggressively swap processes out of
physical memory and move them to swap cache
[/SIZE]
Code:
[SIZE="3"]
[U]dirty_ratio[/U]:
Contains, as a percentage of total system memory,
the number of pages at which a process which is generating
disk writes will itself start writing out dirty data.
Lower the amount of unwritten write cache to reduce lags
when a huge write is required
[SIZE="2"][I][COLOR="Red"]Lower the amount of unwritten write cache to reduce lags when a huge write is required.[/COLOR][/I][/SIZE]
[/SIZE]
Code:
[SIZE="3"]
[U]sched_rt_period_us[/U]: (Real-Time group scheduling)
The scheduling period that is equivalent to 100% CPU bandwidth[/SIZE]
Code:
[SIZE="3"]
[U]
sched_rt_runtime_us[/U]: (Real-Time group scheduling)
A global limit on how much time realtime scheduling may use. Even without
CONFIG_RT_GROUP_SCHED enabled, this will limit time reserved to realtime
processes. With CONFIG_RT_GROUP_SCHED it signifies the total bandwidth
available to all realtime groups.
* Time is specified in us because the interface is s32. This gives an
operating range from 1us to about 35 minutes.
* sched_rt_period_us takes values from 1 to INT_MAX.
* sched_rt_runtime_us takes values from -1 to (INT_MAX - 1).
* A run time of -1 specifies runtime == period, ie. no limit.[/SIZE]
Code:
[SIZE="3"]
[U]laptop_mode[/U]:
When laptop mode is enabled, the Linux will try to be smart about when
to do disk I/O. It gives as much time as possible to be in a low
power state.
If mode is disabled if value is set to zero (0). To enable mode use non
zero value such as 5.
[/SIZE]
Code:
[SIZE="3"]
[U]oom_kill_allocating_task[/U]:
This enables or disables killing the OOM-triggering task in
out-of-memory situations.
If this is set to zero, the OOM killer will scan through the entire tasklist
and select a task based on heuristics to kill. This normally selects a
rogue memory-hogging task that frees up a large amount of memory
when killed.
If this is set to non-zero, the OOM killer simply kills the task that
triggered the out-of-memory condition. This avoids the expensive tasklist
scan.
If panic_on_oom is selected, it takes precedence over whatever value is
used in oom_kill_allocating_task.
The default value is 0.
[/SIZE]
Code:
[SIZE="3"]
[U]panic_on_oom[/U]:
This enables or disables panic on out-of-memory feature.
1 the kernel panics when out-of-memory happens.
0 the kernel will kill some rogue process, by calling oom_kill().
Usually, oom_killer can kill rogue processes and system will survive.
If you want to panic the system rather than killing rogue processes, set
this to 1.
The default value is 0.
[/SIZE]
Code:
[SIZE="3"]
[U]drop_caches[/U]:
Will cause the kernel to drop clean caches, dentries and inodes from
memory, causing that memory to become free.
1 to free pagecache
2 to free dentries and inodes
3 to free pagecache, dentries and inodes
As this is a non-destructive operation, and dirty objects are not
freeable, the user should run "sync" first in order to make sure all
cached objects are freed.
[/SIZE]
Code:
[SIZE="3"]
[U]vfs_cache_pressure[/U]:
Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.
At the default value of vfs_cache_pressure = 100 the kernel will attempt
to reclaim dentries and inodes at a "fair" rate with respect to pagecache
and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel
to prefer to retain dentry and inode caches. Increasing vfs_cache_pressure
beyond 100 causes the kernel to prefer to reclaim dentries and inodes.
[/SIZE]
Code:
[SIZE="3"]
[U]page-cluster[/U]:
controls the number of pages which are written to swap in a single attempt.
The swap I/O size.
It is a logarithmic value
0 means "1 page"
1 means "2 pages"
2 means "4 pages"
3 means "8 pages"
The default value is three (eight pages at a time).
There may be some small benefits in tuning this to a different value
if your workload is swap-intensive.
[/SIZE]
Code:
[SIZE="3"]
[U]min_free_kbytes[/U]:
This is used to force the Linux VM to keep a minimum number of kilobytes
free. The VM uses this number to compute a pages_min value for each
lowmem zone in the system. Each lowmem zone gets a number of reserved
free pages based proportionally on its size
[SIZE="2"][I][COLOR="Red"]Increase minimum free memory, in theory this should make the kernel less likely to
suddenly run out of memory[/COLOR][/I][/SIZE]
[/SIZE]
Code:
[SIZE="3"]
[U]overcommit_memory[/U]:
Controls overcommit of system memory, possibly allowing processes to
allocate (but not use) more memory than is actually available.
0 Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system.
It ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to allocate
slighly more memory in this mode. This is the default.
1 Always overcommit. Appropriate for some scientific applications.
2 Don't overcommit. The total address space commit for the system
is not permitted to exceed swap plus a configurable percentage
(default is 50) of physical RAM. Depending on the percentage
you use, in most situations this means a process will not be
killed while attempting to use already-allocated memory but
will receive errors on memory allocation as appropriate.
[/SIZE]
Code:
[SIZE="3"]
[U]overcommit_ratio[/U]:
Percentage of physical memory size to include in overcommit calculations.
Memory allocation limit = swapspace + physmem * (overcommit_ratio / 100)
swapspace = total size of all swap areas
physmem = size of physical memory in system
[/SIZE]
Code:
[SIZE="3"]
[U]dirty_expire_centisecs[/U]:
This tunable is used to define when dirty data is old enough to be
eligible for writeout by the pdflush daemons. It is expressed in 100'ths
of a second. Data which has been dirty in memory for longer than this
interval will be written out next time a pdflush daemon wakes up.
[/SIZE]
Code:
[SIZE="3"]
[U]dirty_writeback_centisecs[/U]:
The pdflush writeback daemons will periodically wake up and write "old"
data out to disk. This tunable expresses the interval between those
wakeups, in 100'ths of a second.
Setting this to zero disables periodic writeback altogether.
[/SIZE]
Code:
[SIZE="3"]
[U]dirty_background_ratio[/U]:
Contains, as a percentage of total system memory, the number of pages
at which the pdflush background writeback daemon will start writing
out dirty data.
[/SIZE]
Code:
[SIZE="3"]
[U]tainted[/U]:
Non-zero if the kernel has been tainted. Numeric values, which can
be ORed together:
1 a module with a non-GPL license has been loaded, this includes
modules with no license (set by modutils and module-init-tools)
2 a module was force loaded by insmod -f (set by modutils and
module-init-tools)
4 unsafe SMP processors: SMP with CPUs not designed for SMP
8 a module was force unloaded by rmmod -f (set by modutils and
module-init-tools)
16 a machine check exception has occurred
32 system has hit bad_page
[/SIZE]
Code:
[SIZE="3"]
[U]up_threshold[/U]:
this means it will increase the CPU speed when utilization is above x%
percentage values (1 to 100)
[/SIZE]
Code:
[SIZE="3"]
[U]sampling_rate[/U]:
This is how often you want the kernel to look at the CPU usage and to
make decisions on what to do about the frequency. Typically this is set
to values of around '10000' or more. If you wanted to set the sampling
rate to 1 second you would set it to 1000000.
This is measured in microseconds (one millionth of a second).
[/SIZE]
Code:
[SIZE="3"]
[U]lease-break-time[/U]:
This file specifies the grace period (in seconds) that the kernel grants
to a process holding a file lease after it has sent a signal to that
process notifying it that another process is waiting to open the file.
If the lease holder does not remove or downgrade the lease within
this grace period, the kernel forcibly breaks the lease.
[/SIZE]
do you think that it will work with lower end diveces?\
like the htc hero and magic?
stroobach said:
do you think that it will work with lower end diveces?\
like the htc hero and magic?
Click to expand...
Click to collapse
yes, will work ON ALL ANDROID devices
vladnosferatu said:
yes, will work ON ALL ANDROID devices
Click to expand...
Click to collapse
aight i will test this right away
what extantion do i need to save this?
and i suppose it should go into the init.d folder?
(using C++ ofc)
stroobach said:
aight i will test this right away
what extantion do i need to save this?
and i suppose it should go into the init.d folder?
Click to expand...
Click to collapse
yes,
or you can run with a script runner app
i mean with C++.. do i need to save it as a .js file or something else?
stroobach said:
i mean with C++.. do i need to save it as a .js file or something else?
Click to expand...
Click to collapse
no this is a bash script
you can save it "script.sh" or just "script"
than do chmod 755 script
change "echo 1000000 > /proc/sys/kernel/sched_latency_ns" to "echo 10000000 > /proc/sys/kernel/sched_latency_ns"
change "echo 100000 > /proc/sys/kernel/sched_min_granularity_ns" to "echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns"
the MAN is incomplete,
i will update all settings
nice post, if I can suggest... there is a little gain by remounting some partitions without noatime & nodiratime, for ex:
Code:
## NEL DUBBIO ROOT e SYSTEM RIMONTATE IN RW
mount -o remount,rw,noatime /;
mount -o remount,rw,noatime /system;
## RIMONTIAMO LE PARTIZIONI SENZA ATIME, NORELATIME E' UTILIZZATO DA ALCUNE APP
for MountPoint in `mount|cut -d " " -f3`
do
mount -o remount,noatime,nodiratime $MountPoint;
done
and also this below can be used even if I don't know what are real advantages, anyway it doesn't hurt
Code:
## QUESTI NON SONO DISCHI RIGIDI, MEGLIO SPECIFICARE
for Block in /sys/block/*
do
echo deadline > $Block/queue/scheduler;
echo 0 > $Block/queue/rotational;
echo 4 > $Block/queue/iosched/writes_starved;
done
suiller said:
nice post, if I can suggest... there is a little gain by remounting some partitions without noatime & nodiratime, for ex:
Code:
## NEL DUBBIO ROOT e SYSTEM RIMONTATE IN RW
mount -o remount,rw,noatime /;
mount -o remount,rw,noatime /system;
## RIMONTIAMO LE PARTIZIONI SENZA ATIME, NORELATIME E' UTILIZZATO DA ALCUNE APP
for MountPoint in `mount|cut -d " " -f3`
do
mount -o remount,noatime,nodiratime $MountPoint;
done
and also this below can be used even if I don't know what are real advantages, anyway it doesn't hurt
Code:
## QUESTI NON SONO DISCHI RIGIDI, MEGLIO SPECIFICARE
for Block in /sys/block/*
do
echo deadline > $Block/queue/scheduler;
echo 0 > $Block/queue/rotational;
echo 4 > $Block/queue/iosched/writes_starved;
done
Click to expand...
Click to collapse
thanks
can you translate the comments to english ?
Thanks very much!
sure friend
Code:
## JUST IN CASE... ROOT and SYSTEM REMOUNT AS ReadWrite
mount -o remount,rw,noatime /;
mount -o remount,rw,noatime /system;
## REMOUNT ALL PARTITIONS WITHOUT ATIME, NORELATIME IS USED BY SOME APPs
for MountPoint in `mount|cut -d " " -f3`
do
mount -o remount,noatime,nodiratime $MountPoint;
done
Code:
## THESE ARE NOT PHYSICAL HardDrive
for Block in /sys/block/*
do
echo deadline > $Block/queue/scheduler;
echo 0 > $Block/queue/rotational;
echo 4 > $Block/queue/iosched/writes_starved;
done
Anyway I have some doubts about touching vm parts
For ex cache pressure can make the device sluggish after some time
While I think that modifing kernel timings can be a good idea even if I used a different approuch by using different configs between wakeup & sleeping
Sent from my HTC Desire using Tapatalk
added script:
GOOD PERFORMANCE AND GOOD BATTERY LIFE
Thanks
is it work with custom kernel like faux 0.2.4r
can i use it like this :
init.post_boot.sh
#!/system/bin/shtarget=`getprop ro.board.platform`case "$target" in "msm8660")
echo 50000 > /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/sampling_rate
echo 90 > /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/up_threshold
echo 1 > /sys/devices/system/cpu/cpufreq/IntelliDemand/io_is_busy
echo 5 > /sys/devices/system/cpu/cpufreq/IntelliDemand/sampling_down_factor
echo 192000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 100000 > /proc/sys/kernel/sched_rt_period_us
echo 95000 > /proc/sys/kernel/sched_rt_runtime_us
echo 0 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/dirty_ratio
echo 4 > /proc/sys/vm/dirty_background_ratio
echo 4096 > /proc/sys/vm/min_free_kbytes
echo 5 > /proc/sys/vm/vfs_cache_pressure
echo 0 > /proc/sys/vm/oom_kill_allocating_task
echo 0 > /proc/sys/vm/laptop_mode
echo 0 > /proc/sys/vm/panic_on_oom
echo 0 > /proc/sys/kernel/tainted
echo 3 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/page-cluster
echo 10 > /proc/sys/fs/lease-break-time
echo 1 > /proc/sys/vm/overcommit_memory
echo 100 > /proc/sys/vm/overcommit_ratio
echo 500 > /proc/sys/vm/dirty_expire_centisecs
echo 1000 > /proc/sys/vm/dirty_writeback_centisecs
echo 10000000 > /proc/sys/kernel/sched_latency_ns
echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns
echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns
echo 725000 > /proc/sys/kernel/sched_shares_ratelimit
chown system /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/sampling_rate
chown system /sys/devices/system/cpu/cpu0/online
chown system /sys/devices/system/cpu/cpu1/online
chown system /sys/power/perflock
;;
esac
i changed ondemand to IntelliDemand because faux use this Governor .
is it right what i did???????
mamdouhn said:
Thanks
is it work with custom kernel like faux 0.2.4r
can i use it like this :
init.post_boot.sh
#!/system/bin/shtarget=`getprop ro.board.platform`case "$target" in "msm8660")
echo 50000 > /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/sampling_rate
echo 90 > /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/up_threshold
echo 1 > /sys/devices/system/cpu/cpufreq/IntelliDemand/io_is_busy
echo 5 > /sys/devices/system/cpu/cpufreq/IntelliDemand/sampling_down_factor
echo 192000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 100000 > /proc/sys/kernel/sched_rt_period_us
echo 95000 > /proc/sys/kernel/sched_rt_runtime_us
echo 0 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/dirty_ratio
echo 4 > /proc/sys/vm/dirty_background_ratio
echo 4096 > /proc/sys/vm/min_free_kbytes
echo 5 > /proc/sys/vm/vfs_cache_pressure
echo 0 > /proc/sys/vm/oom_kill_allocating_task
echo 0 > /proc/sys/vm/laptop_mode
echo 0 > /proc/sys/vm/panic_on_oom
echo 0 > /proc/sys/kernel/tainted
echo 3 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/page-cluster
echo 10 > /proc/sys/fs/lease-break-time
echo 1 > /proc/sys/vm/overcommit_memory
echo 100 > /proc/sys/vm/overcommit_ratio
echo 500 > /proc/sys/vm/dirty_expire_centisecs
echo 1000 > /proc/sys/vm/dirty_writeback_centisecs
echo 10000000 > /proc/sys/kernel/sched_latency_ns
echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns
echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns
echo 725000 > /proc/sys/kernel/sched_shares_ratelimit
chown system /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/sampling_rate
chown system /sys/devices/system/cpu/cpu0/online
chown system /sys/devices/system/cpu/cpu1/online
chown system /sys/power/perflock
;;
esac
i changed ondemand to IntelliDemand because faux use this Governor .
is it right what i did???????
Click to expand...
Click to collapse
Why do you chown system /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/sampling_rate ? You also don't need chown system /sys/power/perflock since it's gone with custom kernels.
mike1986. said:
Why do you chown system /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/sampling_rate ? You also don't need chown system /sys/power/perflock since it's gone with custom kernels.
Click to expand...
Click to collapse
Thanks mike do i need to delete something else???
#!/system/bin/sh
target=`getprop ro.board.platform`case "$target" in"msm8660"
echo 50000 > /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/sampling_rate
echo 90 > /sys/devices/system/cpu/cpu0/cpufreq/IntelliDemand/up_threshold
echo 1 > /sys/devices/system/cpu/cpufreq/IntelliDemand/io_is_busy
echo 5 > /sys/devices/system/cpu/cpufreq/IntelliDemand/sampling_down_factor
echo 192000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 100000 > /proc/sys/kernel/sched_rt_period_us
echo 95000 > /proc/sys/kernel/sched_rt_runtime_us
echo 0 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/dirty_ratio
echo 4 > /proc/sys/vm/dirty_background_ratio
echo 4096 > /proc/sys/vm/min_free_kbytes
echo 5 > /proc/sys/vm/vfs_cache_pressure
echo 0 > /proc/sys/vm/oom_kill_allocating_task
echo 0 > /proc/sys/vm/laptop_mode
echo 0 > /proc/sys/vm/panic_on_oom
echo 0 > /proc/sys/kernel/tainted
echo 3 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/page-cluster
echo 10 > /proc/sys/fs/lease-break-time
echo 1 > /proc/sys/vm/overcommit_memory
echo 100 > /proc/sys/vm/overcommit_ratio
echo 500 > /proc/sys/vm/dirty_expire_centisecs
echo 1000 > /proc/sys/vm/dirty_writeback_centisecs
echo 10000000 > /proc/sys/kernel/sched_latency_ns
echo 0 > /proc/sys/kernel/sched_wakeup_granularity_ns
echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns
echo 725000 > /proc/sys/kernel/sched_shares_ratelimit
chown system /sys/devices/system/cpu/cpu0/online
chown system /sys/devices/system/cpu/cpu1/online
;;
esac
mamdouhn said:
Thanks mike do i need to delete something else???
Click to expand...
Click to collapse
Well it depends. Ton of the settings in both scripts are useless because they set already default values. f.g. laptop_mode is 0 by default and you don't need to set it in separate script.
mike1986. said:
Well it depends. Ton of the settings in both scripts are useless because they set already default values. f.g. laptop_mode is 0 by default and you don't need to set it in separate script.
Click to expand...
Click to collapse
can you give to me a good script to use with faux kernel 2.4r and Europe 1.45.401.2 Base - Android 2.3.4 // Sense 3.0 please??????
Related
First, I would like to thank the GOT team, kabaldan and others for getting the Froyo on our milestone earlier than expected!
Based on what some other members said, here's what I concluded on how to improve the battery life:
1. Just to mention I'm overclocked at 800mhz with 52vsel
2. I have deleted ADWLauncher.apk and replaced it with Launcherpro (this doesnt have an effect on battery, it's just that I like this launcher because it's more faster and more responsive)
3. I also deleted CMstats.apk from /system/app
4. I have disabled "location" from setting-->location and security settings-->my location ... both "use wireless" and "use gps" are disabled
! This seems to have the most important effect on the battery!
5. Just to mention I'm also using the "Conservative governor" with SetCpu
Hope's this help you as it does to me!
the only thing i did that i really noticed battery improvemts was on set cpu create a profile for screen off with 250/250 speeds usually i had 250/500 and my phone wouldn´t last a day with the new froyo roms but at 250/250 screen off i can easily get to a day, day and a half
my tabe
Code:
#!/system/bin/sh
insmod /system/lib/modules/overclock.ko
echo 56 > /proc/overclock/max_vsel
echo 1000000 > /proc/overclock/max_rate
#echo "5 1000000000 56" > /proc/overclock/mpu_opps
echo "4 750000000 42" > /proc/overclock/mpu_opps
echo "3 500000000 30" > /proc/overclock/mpu_opps
echo "2 250000000 20" > /proc/overclock/mpu_opps
#echo "1 125000000 20" > /proc/overclock/mpu_opps
#echo "0 1000000" > /proc/overclock/freq_table
echo "1 750000" > /proc/overclock/freq_table
echo "2 500000" > /proc/overclock/freq_table
echo "3 250000" > /proc/overclock/freq_table
insmod /system/lib/modules/cpufreq_interactive.ko
echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
#insmod /system/lib/modules/cpufreq_conservative.ko
#echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
#echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate
#echo 25 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/freq_step
work great no random reboots,
Im using in setCPU, screen off profile 500/250mhz
and "toggle 2g" auto manage 2g/3g
2g when sleep
sleep dealy 2min - when screen off
have disabled wireless and gps in "location"
but for 10h sleep mode battery life -20%
I mainly use my xt720 for phone calls, internet browsing/chatting, music,.. not any cpu intensive stuffs. My main concern for my phone is battery. Currently, these are the 2 things I have done to possibly prolong my battery charge:
1) Milestone overclock --> running at 720mhz @ 40vsel
2) setCPU --> set minimum to 150mhz (maximum remains at 720mhz)
Am I doing right?
Another question is, when I set it to run at 720mhz @ 40vsel, will the phone still use 40vsel at 150mhz when idling/screen off? or does the phone itself bring the vsel lower during 150mhz idling time? if not, are there possible ways to undervolt at each individual cpu speed level?
thank you for your help, any suggestion is appreciated
my save mode script use 125/28~350/32
but it has no perfomance problem for base work and call
dateno1 said:
my save mode script use 125/28~350/32
but it has no perfomance problem for base work and call
Click to expand...
Click to collapse
thanks for the reply!
do you mind telling me what the "save mode script" is? is that part of milestone overclock or SetCPU? Please give future steps
I think i finally figured it out... PLEASE let me know if I'm doing anything wrong
1) setCPU --> minimum to 125mhz, max. to 720mhz
2) created "oc-settings" file with the following lines:
#!/system/bin/sh
echo 40 > /proc/overclock/max_vsel
echo 720000 > /proc/overclock/max_rate
echo 1 125000000 12 > /proc/overclock/mpu_opps
echo 2 250000000 26 > /proc/overclock/mpu_opps
echo 3 400000000 30 > /proc/overclock/mpu_opps
echo 4 600000000 34 > /proc/overclock/mpu_opps
echo 5 720000000 40 > /proc/overclock/mpu_opps
echo 0 720000 > /proc/overclock/freq_table
echo 1 600000 > /proc/overclock/freq_table
echo 2 400000 > /proc/overclock/freq_table
echo 3 250000 > /proc/overclock/freq_table
echo 4 125000 > /proc/overclock/freq_table
Click to expand...
Click to collapse
I rebooted the phone and checked the "/proc/overclock/mpu_opps" file and the frequency/vsel values have been updated to the ones above.
If I am doing it correctly, then everytime the phone reboots, I would have the following frequency/vsel:
125mhz - 12vsel
250mhz - 26vsel
400mhz - 30vsel
600mhz - 34vsel
720mhz - 40vsel
Please let me know if I did it correctly. I cannot find a way to verify whether I have successfully set these vsels into each frequency, and SetCPU does not seem to display vsel values.
Also, in setCPU, where it tells you the time spent in each frequency, it still lists the frequency as 125,250,500,550,720.
Hey imhaving an issue with my underclock... I have it set to 250 500 900 and 1200 and it seems to get stuck on 500 after its running for a while, and the only thing that fixes it is to restart the phone any ideas why this is happening?
I eventually stopped underclocking to 250 because of this.
You might try altering the up and down thresholds in the governor settings in SetCPU (or similar apps or maybe manually echoing them to the proc governor structure).
I never really bothered messing with it as the battery life with the extended battery is amazing anyway
moofree said:
I eventually stopped underclocking to 250 because of this.
You might try altering the up and down thresholds in the governor settings in SetCPU (or similar apps or maybe manually echoing them to the proc governor structure).
I never really bothered messing with it as the battery life with the extended battery is amazing anyway
Click to expand...
Click to collapse
Right on maybe ill try using set CPU I don't cause its not necisary... I've never had this problem before with 250 until now.... what about the frequencies setting after the actual 250 setting could that help?
EDIT --- SET CPU DOES NOT FIX THIS PROB.... any other ideas anyone?
EDIT2--- My buddy that knows more than me is going to mess with the uv voltages and see if that is the issue, i think its something in the backbground that wont die when i kill processes....?????
Edit 3... been working with my friend here are my new settings if anyone wants to use them .... working really well....
#!/system/bin/sh
#
# init.d script for Milestone Overclock Simplified version 1.5
if [ -e /system/lib/modules/symsearch.ko ]; then
insmod /system/lib/modules/symsearch.ko
if [ $? -eq 0 ]; then
echo "symsearch.ko loaded!"
if [ -e /system/lib/modules/overclock.ko ]; then
insmod /system/lib/modules/overclock.ko
if [ $? -eq 0 ]; then
echo "overclock.ko loaded!"
else
echo "Damn, overclock.ko failed to load"
fi
else
echo "Damn, overclock.ko missing"
fi
else
echo "Damn, symsearch.ko failed to load"
fi
else
echo "Damn, symsearch.ko missing"
fi
# MPU a.k.a. CPU Overclocking, edit to suit your needs
#
# *** Warning, only run custom settings at boot after thoroughly testing. ***
#
# Uncomment and modify for your device. The numbers below are known
# stock settings. If you have device not listed here, please run the
# following command, and send the output to [email protected]
# Your stock settings will be added. This is also how you can verify
# changes you've made. From teminal/adb/script:
#
# cat /proc/overclock/*
#
# The format for modifying frequency for a given CPU slot is as follows.
#
# echo <opp_id> <frequency_in_hz> <uV_voltage> > /proc/overclock/mpu_opps
#
if [ -e /proc/overclock/mpu_opps ]; then
# Droid3/Bionic/Atrix2 stock Settings
echo 3 1200000000 1405000 > /proc/overclock/mpu_opps
echo 2 840000000 1357000 > /proc/overclock/mpu_opps
echo 1 500000000 1217000 > /proc/overclock/mpu_opps
echo 0 250000000 1105000 > /proc/overclock/mpu_opps
fi
# GPU Overclocking, uncomment the line with desired frequency
#
# Stock: 307.2MHz
# Underclock: 256MHz
# Overclock: 384MHz
#
if [ -e /proc/overclock/gpu_opps ]; then
echo 250000000 > /proc/overclock/gpu_opps
# echo 384000000 > /proc/overclock/gpu_opps
fi
This is a collection of echo scripts with optimized values for our janice (i9070&i9070P).
I will add an explanation for every tweak to make things clear.
BATTERY
Code:
[COLOR="Red"]deepest_state[/COLOR]: this allow you to set a sleep level. As far as I know, 3-4-5 states are available; major is the state, better your phone will sleep and so less battery draining (obviously while screen is off).
A tip: I think that 4 state is the best, it doesn't cause troubles on the contrary of the 5 level that may causes problems, but it is stable if using ONDEMAND as governor.
[COLOR="Blue"]echo "4" > /d/cpuidle/deepest_state;[/COLOR]
Code:
[COLOR="Red"]dirty_expire_centisecs[/COLOR]: In hundredths of a second, how old data must be to be written out next time a thread wakes to perform periodic writeback. As I know, permitted values are 100 to 5000, but if I'm wrong, don't esitate to correct me!
[COLOR="Blue"]echo "5000" > /proc/sys/vm/dirty_expire_centisecs;[/COLOR]
Code:
[COLOR="Red"]dirty_writeback_centisecs[/COLOR]: In hundredths of a second, how often threads should wake up to write data back out to disk.
[COLOR="Blue"]echo "5000" > /proc/sys/vm/dirty_writeback_centisecs;[/COLOR]
Code:
[COLOR="Red"]laptop_mode[/COLOR]: is a special page writeback strategy intended to optimize battery life by minimizing memory activity. My tip is to take it off.
[COLOR="Blue"]echo "0" > /proc/sys/vm/laptop_mode;[/COLOR]
Code:
[COLOR="Red"]max_ac_c[/COLOR]: Is a CoCore kernel feature that allow to edit the chargin' values. Safe values are among 100 to 700, put an higher value may damage your battery, instead putting lower value (400 for example) it will preserve battery life.
[COLOR="blue"]echo "400" > /sys/kernel/abb-charger/max_ac_c;[/COLOR]
PERFORMANCE
Code:
[COLOR="Red"]mali_l2_max_reads[/COLOR]: Set max reads that mali l2 can do.
[COLOR="Blue"]echo "48" > /sys/module/mali/parameters/mali_l2_max_reads;[/COLOR]
Code:
[COLOR="Red"]mali_debug_level[/COLOR]: Disabling it, you can gain some performance improvements.
[COLOR="Blue"]echo "0" > /sys/module/mali/parameters/mali_debug_level;[/COLOR]
Code:
[COLOR="Red"]fsync[/COLOR]: Fsync is an android capability that always writes data out to the memory preventing data loss. If you have a stable system, disable it and you'll have: more battery life, faster system. But be careful you may loose all of your data if your phone shuts down suddenly.
[COLOR="Blue"]echo "0" > /sys/kernel/fsync/mode;[/COLOR] // To enable (default)
[COLOR="Blue"]echo "1" > /sys/kernel/fsync/mode;[/COLOR] // To disable
[COLOR="Blue"]echo "2" > /sys/kernel/fsync/mode;[/COLOR] // Dynamic (writes data only when screen is off)
Code:
[COLOR="Red"]vfs_cache_pressure[/COLOR]: File system cache is really more important than the block cache above in dirty ratio and dirty background ratio, so we really want the kernel to use up much more of the RAM for file system cache, this will increase the performance of the system without sacrificing performance at the application level. Lower value is better (100 is the max), so for example:
[COLOR="Blue"]echo "10" > /proc/sys/vm/vfs_cache_pressure;[/COLOR]
Code:
[COLOR="red"]page-cluster[/COLOR]: This controls the number of pages which are written to swap in a single attempt.
It is a logarithmic value - setting it to zero means "1 page", setting it to 1 means "2 pages", setting it to 2 means "4 pages", etc.
[COLOR="Blue"]echo "3" > /proc/sys/vm/page-cluster;[/COLOR]
SD CARD
Code:
The default value of sd card cache is 128, but some various tests have estabilished that if you increase this value to 2048, you'll have improvements in write and read sd card operations.
[COLOR="Blue"]echo "2048" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:0/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:1/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:2/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:3/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:4/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:5/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:6/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/7:7/read_ahead_kb;
echo "2048" > /sys/devices/virtual/bdi/default/read_ahead_kb;[/COLOR]
Code:
[COLOR="Blue"]This should block charging when phone reaches 100% and recharge phone when is 50% (Thanks to [user=2855249]@bobfrantic[/user]).
THIS IS ONLY WORKING WITH COCORE KERNEL[/COLOR]
echo on > /sys/kernel/abb-fg/fg_cyc
echo dischar=100 > /sys/kernel/abb-fg/fg_cyc
echo rechar=50 > /sys/kernel/abb-fg/fg_cyc
I will add more tweaks, stay tuned guys
@hastalafiesta
No DL on OP?
---------- Post added at 02:56 AM ---------- Previous post was at 02:47 AM ----------
Do you have Purging of assets and kernel sampage merging enabled manually in AOSPA with this script? Or only KSM?
Thanks
coffeecore said:
@hastalafiesta
No DL on OP?
---------- Post added at 02:56 AM ---------- Previous post was at 02:47 AM ----------
Do you have Purging of assets and kernel sampage merging enabled manually in AOSPA with this script? Or only KSM?
Thanks
Click to expand...
Click to collapse
I will also add here a script. Nope both (ksm and purging of assets) disabled
Hi. I'm trying to optimize some computer vision code, but variable CPU core frequencies is making it extremely hard to quantify any improvements I make. Basically I want to be able to force all 4 cores to 2.26GHz so that my test environment can be consistent. I'm currently running rooted Lineage OS 14.1.
I have tried doing the following through a root shell:
Code:
stop mpdecision
echo "1" > /sys/devices/system/cpu/cpu0/online
echo "1" > /sys/devices/system/cpu/cpu1/online
echo "1" > /sys/devices/system/cpu/cpu2/online
echo "1" > /sys/devices/system/cpu/cpu3/online
echo "2265000"> /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "2265000"> /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
echo "2265000"> /sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq
echo "2265000"> /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq
echo "2265000"> /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "2265000"> /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
echo "2265000"> /sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq
echo "2265000"> /sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq
After doing this, CPU-Z shows all 4 cores running at 2.26GHz - great! But, while running my code, the performance immediately starts to drop. Upon re-opening CPU-Z, it shows all 4 cores running at ~1500-1900MHz. What gives?
Thermal throttling.
You need to delete or modify /system/etc/thermal-engine-8974.conf
Note: This could make your device run really hot.
Kotaless said:
Thermal throttling.
You need to delete or modify /system/etc/thermal-engine-8974.conf
Note: This could make your device run really hot.
Click to expand...
Click to collapse
Ah, ok, I had a hunch it might be that. Any guidance on max safe temp? Somewhere around 85C maybe? I can always put the phone on top of an icepack while running my code hahaha
Also, which value do I need to modify?
Code:
[CPU0_MONITOR]
algo_type monitor
sensor cpu0
sampling 65
thresholds 115000
thresholds_clr 110000
actions shutdown
action_info 0
Ok so I did some testing, without modifying the thermal-engine.conf file, here's what I found:
Code:
Applying load, idling at 45C:
Runs at 2.26GHz until hitting 67C;
Runs at 1.96GHz for a little bit;
Settles at 1.57Ghz @ 66C
When removing load:
Starting at 1.57GHz @ 65C
Ramps up to 1.96GHz @ 53C
Ramps up to 2.26GHz @ 51C
It looks like throttling starts at 67C and ends at 51C, but none of those values appear in the thermal-engine file. The only value that even looks remotely close is the sampling value, but I'm assuming that's some sort of sampling interval parameter, no?
Well I found a Qualcomm PDF about the DragonBoard 410 that happened to mention
Code:
~# stop thermal-engine
and what do you know, it must apply to the SD800 too, because it worked
Good for you.
I modified this part for myself.
Code:
[SKIN_THERMAL_management_1]
algo_type monitor
sensor xo_therm_pu2
sampling 10000
thresholds 40000 42000 44000
thresholds_clr 38500 40500 42500
actions cpu+lcd cpu+lcd cpu+lcd
action_info 1958400+229 1728000+204 1574400+178