[SENSE KERNEL] no longer maintained
- Thread starter coutts99
- Start date
- Status
Ok I got bored and built it
http://mirror.couttstech.com/android/bravo/kernel/OC1190_HAVS@875_BFS_BFQ_OCCamera.zip
OC1190 Havs@875 BFS/BFQ Camera Overclock
I haven't flashed or tested this at all yet, I am not responsible for any damage this kernel may cause to your device
installed at the moment, everything works right, camera, camcorder, I'll see if I do some video and check if there is really improvement in terms of fps
I made a video when we are with practically little light, and with vlc, I get 27 fps ends tomorrow proves it more carefully and more light
Rom leedroid 2f and last radio
Rom leedroid 2f and last radio
I made a video of a TV in white artificial light, I managed to have about 19FPS. Before the patch I had 16FPS. This is in very bad conditions, at day light I should manage ~27FPS. One annoyance though, the audio is faster than the video in bad light when using a Sense HD ROM.
I could not check the audio track, I made the video from the window shut because quite cold 
, however proves morning with more light and more detail.
, however proves morning with more light and more detail.
Any chance you could do a version without the battery fix? I'm a bit worried about shortening my battery's life...
@coutts99
Hey, is it possible that you provide a version of your kernel without HAVS changes from rt's kernel. I do have (rare) fcs with your kernel when cpu load/clock jumps from 0%/245mhz to 100%/1113mhz. This did not happen on snq's 2.2f kernel.
I think this is related either to the way HAVS work (maybe clock adjusted faster than mV?) or to the mV values (for 245: 950mV on snqs and 925mV on yours - don't know the others mV values).
Since I really started to like bfs I would prefer your kernel, but stability has priority.
Sent from my HTC Desire using XDA App
Hey, is it possible that you provide a version of your kernel without HAVS changes from rt's kernel. I do have (rare) fcs with your kernel when cpu load/clock jumps from 0%/245mhz to 100%/1113mhz. This did not happen on snq's 2.2f kernel.
I think this is related either to the way HAVS work (maybe clock adjusted faster than mV?) or to the mV values (for 245: 950mV on snqs and 925mV on yours - don't know the others mV values).
Since I really started to like bfs I would prefer your kernel, but stability has priority.
Sent from my HTC Desire using XDA App
Ok, I did some debugging on the 925 mhz bfs kernel and I found the reason for the instability:
Dmsg:
"AVS: Voltage can not get high enough!"
This happens for mV above 1275. So 1113 is unstable for me due to 25 mV to low voltage.
Also I think that HAVS wont reduce battery drain. Since most time avs sets the mV even higher then the values on snq's kernel.
example from dmsg:
AVS setting V to 1000 mV @256 MHz
I didn't find one value that is actually BELOW the values of snq's kernel.
And on Top of that the cpu stays more time on higher clock speeds (checked with setcpu - info) when phone is idle (screen on - tested under 100% same conditions). This may also be due to havs needing recources to adjust the values (ill do some more tests to rule out that it's not the sheduler that is consuming resources).
So i really think that HAVS sucks ...
I'm back to snqs kernel for now. If I have time I'll make some test regarding BFS/CFS, as I think BFS might be better.
Btw: I don't want you to understand my post as offensive in any way. Since i can't code i simply want to contribute to all the the great work at xda by testing/bug reporting/etc ...
Sent from my HTC Desire using XDA App
Dmsg:
"AVS: Voltage can not get high enough!"
This happens for mV above 1275. So 1113 is unstable for me due to 25 mV to low voltage.
Also I think that HAVS wont reduce battery drain. Since most time avs sets the mV even higher then the values on snq's kernel.
example from dmsg:
AVS setting V to 1000 mV @256 MHz
I didn't find one value that is actually BELOW the values of snq's kernel.
And on Top of that the cpu stays more time on higher clock speeds (checked with setcpu - info) when phone is idle (screen on - tested under 100% same conditions). This may also be due to havs needing recources to adjust the values (ill do some more tests to rule out that it's not the sheduler that is consuming resources).
So i really think that HAVS sucks ...
I'm back to snqs kernel for now. If I have time I'll make some test regarding BFS/CFS, as I think BFS might be better.
Btw: I don't want you to understand my post as offensive in any way. Since i can't code i simply want to contribute to all the the great work at xda by testing/bug reporting/etc ...
Sent from my HTC Desire using XDA App
vdd level patch
Used this kernel for a few days and works fairly well. Does this kernel include the "vdd level" patch (link below)? I have a basic init.d script I use to set the max frequency, couldn't get it to work with this kernel.
http://xdaforums.com/showthread.php?t=821372
Used this kernel for a few days and works fairly well. Does this kernel include the "vdd level" patch (link below)? I have a basic init.d script I use to set the max frequency, couldn't get it to work with this kernel.
http://xdaforums.com/showthread.php?t=821372
Yes it does (try "cat /sys/devices/system/cpu/cpu0/cpufreq/vdd_levels" in terminal or adb shell). Its based on snqs kernel.
BUT !!! Since it has HAVS this is useless. HAVS readjust the mV values dynamicly.
Sent from my HTC Desire using XDA App
Thanks for clarifying. I'll give it another try later. Most likely something i'm doing incorrectly. I'm not touching the vdd levels at all. Only value i'm changing in my init.d script is scaling_max_freq. The script doesn't seem to be executing. I've swapped kernels and it is only happening with this kernel.
I ran the following in adb shell to check the max cpu frequency. Basically same as in your post except changing vdd_levels to scaling_max_freq.
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
Last edited:
Camera patcg kernel above works nice
I did am identical test with a 21 second video @720p and this is what I got in low light:
Stock Leedroid kernel:
OC1190_HAVS@875_BFS_BFQ_OCCamera.zip
Bitrate is a bit higher and max framerate is much higher. Will have to test during the daytime but I tend to use 480p either way with mpeg4 codec because the filesizes are easier to upload for youtube.
I did am identical test with a 21 second video @720p and this is what I got in low light:
Stock Leedroid kernel:
Code:
Bit rate : 3 613 Kbps
Frame rate : 10.000 fps
Minimum frame rate : 3.745 fps
Maximum frame rate : 27.027 fpsOC1190_HAVS@875_BFS_BFQ_OCCamera.zip
Code:
Bit rate : 4 087 Kbps
Frame rate : 11.481 fps
Minimum frame rate : 4.082 fps
Maximum frame rate : 45.455 fpsBitrate is a bit higher and max framerate is much higher. Will have to test during the daytime but I tend to use 480p either way with mpeg4 codec because the filesizes are easier to upload for youtube.
Last edited:
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
36I forked LeeDroid v2.2f, so we have all usual patches (GPU, SDFix etc), kernel is then patched it up to 2.6.32.27.
BFS363,
VR IO Scheduler enabled. Why? These benchmarks - http://xdaforums.com/showpost.php?p=10669818&postcount=591
SLQB slab allocator enabled
Sibere charging fix applied (thanks to sibere)
HAVS@875mV and 925mV (Thanks to Richard Trip)
vorkKernel compiler optimisations. (Thanks to benee)
Camera Overclock (Thanks to Cyanogen!)
Various Cyanogenmod patches (Thanks to Cyanongen for the fantastic job they do!)
**DISCLAIMER**** I don't take any responsibility for any damage this kernel may cause to your device.
Only use this if you have a Sense ROM (no defrost/cyanogenmod/AOSPDesire/opendesire/). It works great with the new HD roms.
Download at http://mirror.couttstech.com/android/index.php?dir=bravo/kernel/Sense/BFS/
DO NOT GO POKING ABOUT IN SUB FOLDERS OR DOWNLOADING ANYTHING WITH TEST IN THE NAME
"couttstech-2.6.32.28_OC1190_HAVS@875mV_BFS_VR.zip"
"couttstech-2.6.32.28_OC1190_HAVS@925mV_BFS_VR.zip"
"couttstech-2.6.32.28_OC1190_BFS_VR.zip"
CFS versions download at http://mirror.couttstech.com/android/index.php?dir=bravo/kernel/Sense/CFS/-:
"couttstech-2.6.32.28_OC1190_HAVS@875mV_CFS_VR.zip"
"couttstech-2.6.32.28_OC1190_HAVS@925mV_CFS_VR.zip"
"couttstech-2.6.32.28_OC1190_CFS_VR.zip"
Please visit the sponsors and help pay for bandwidth!
Source -
git://git.couttstech.com/couttstech-bravo.git
***CHANGES
24 - Nov - 2010 - Changed from SLAB to SLUB
24 - Nov - 2010 - Latest HTC kernel updates patched (Thanks to ziggys kernel for this patch)
25 - Nov - 2010 - Added 128MHz as requested
27 - Nov - 2010 - Audiomod added to BFS kernels
05 - Dec - 2010 - Removed OC1113 kernels
05 - Dec - 2010 - Added camera overclock patch ( http://review.cyanogenmod.com/#change,35 )
05 - Dec - 2010 - Various cyanogen patches applied see git log for details
05 - Dec - 2010 - Change from SLUB to SLQB slab allocator
06 - Dec - 2010 - Change to ondemand by default (initial testing showing better battery life with HAVS, thanks melethron)
07 - Dec - 2010 - HAVS SetCPU clock speed out by one step issue fixed.
09 - Dec - 2010 - Changed Audio min gain for handset and headset
10 - Dec - 2010 - Added AUFS module
14 - Dec - 2010 - Patched to 2.6.32.27
16 - Dec - 2010 - BFS patched to version 360
17 - Dec - 2010 - Charging on lock screen fix included (many thanks to snq-)
23 - Dec - 2010 - Headset max gain lowered, also video compiled into kernel instead of being modules
01 - Jan - 2011 - BFS updated to v363
06 - Jan - 2011 - Full ck2 patch set applied (for BFS kernels)
09 - Jan - 2011 - Car dock working
09 - Jan - 2011 - Revert to stock battery driver
09 - Jan - 2011 - Sibere battery fix applied
09 - Jan - 2011 - Patched to 2.6.32.28
09 - Jan - 2011 - Reiserfs enabled
09 - Jan - 2011 - CFS builds added
10 - Jan - 2011 - CGROUPS sorted on CFS builds
11 - Jan - 2011 - Voltages raised for higher freq on SVS versions, should be stable for all now
14 - Jan - 2011 - Revert ck2 patch set for BFS kernels
17 - Jan - 2011 - Switch to VR IO Scheduler as default
Full changelog -:
http://git.couttstech.com/?p=couttstech-bravo.git;a=summary
IRC - irc.freenode.net - #coutts9910
An explanation how this all works. Ondemand has a sampling rate of 20ms default. This means that the govenor checks every 20ms if it needs to change clocks. This means that there can be a delay of up to 20ms (worst case) to let the clock jump up. (if you play/played online game you may have a "feeling" for what this value feels like as ping. But note that ondemand hasn't a constant latency of 20ms but is somewhere between 0 and 20ms ... so not everytime "feelable")
Interactive/smartass works different. They take over the "idle" process. Through this the change of clocks is almost "instant".
This is at least the theory but in my opinion smartass in indeed faster. Also the threshold (95% at ondemand) isn't needed then. This means it wont jump from 245->998->245 but also goes to medium values. The difference between smartass is not feelable in most cases (but it is if you watch closely it is slower). If you bench then is also noticeable because the latency of ondemand will sum up and you may stay like 100-200ms (pure guessing maybe much more) or something on a low clock when a high clock is needed. Thus the lower score.
Now to HAVS. HAVS changes values dynamically depending on system load. This means if the cpu jumps up while there is only a short spike the voltage wont be set as high. This is good on ondemand because it has those spikes because of those jumps from the needed high threshold (and you if you reduce the treshhold it will go up too slow if its needed 245>556>998 with a delay between 20ms and 40ms so changing that is not a good idea).
As smartass is changing clocks much more often it has a side effect with smartass. HAVS needs to calculate the values more often than with ondemand. In general HAVS isnt more stable on ondemand than on smartass, but there is a physical issue. If a voltage is change to a higher value by a conductor it needs to build up a higher "electrical charge". This means that voltage switching is physically delayed (its really short time but its testable). If your cpu is stable on 875mv on 245mhz and stable on 1275mv at 998mhz it can be still unstable if it jumps from 245 to 998 (because of the physical delay the 998 may not have the full 1275mv). I had instabilities because of this with an older version of coutts kernel. On "performance" (means CONSTANT high value) 998@1275 and on powersave (CONSTANT low clock) with 245@925 it was stable. When i switched to smartass/ondemand it has gotten unstable .... so this is not just some physical theory it's also practice (btw: a theory that doesnt apply to practice is wrong ). Now as i said this issue is there on both governors but it applies more often on smartass because of the faster switching of clocks. This is why ondemand is more stable in combination with HAVS.
Now as i said the dynamically switching of voltages from HAVS is good to keep a lower overall voltage on spikes it is a bit different with smartass. Since smartass uses the idle process the governor ITSELF is more adjusted to actual system load. This makes HAVS redundant in my opinion. If you watch the "info" tap in set cpu you'll see that smartass will stay a.) more time on lower or medium clocks and b.) doesnt "spike" that much. So the voltages set by SVS (svs sets the voltage statically to a value ... the mV for every clock is fixed) will be lower than on ondemand and this makes HAVS obsolete imo.
To summerize:
ondemand is a "static" adjustment of clock (every 20ms)
smartass is dynamic depending on system load (through idle process)
SVS sets voltages statically depending on clock
HAVS sets voltages dynamically depending on system load.
This means then that smartass + svs is completly dynamical on its own. Because if the clock is dynamically changed the "static" voltages are dynamic because of the dynamic clock.
This makes HAVS then reduntant. Since SVS doesnt need time to calculate the mV values it means
a). less to do for the cpu (but thats not much anyway ... but still there is)
b). Without calculation the switching is faster and thus a bit more stable (havs adds calculation time to the physical delay).
So much for the theory. But what about reallife? Test it on your own
I never found any power advantages from HAVS in conjunction with smartass (on daily use). This makes HAVS practically "dead code". Since i constantly calculates values that aren't needed and it is slightly more unstable. I'll stick to SVS + smartass.
EDIT: @coutts: It's funny. I got a freeze in recovery with your svs cfs 1275 kernel. After flash it was idle and my cpu couldn't handle the voltage. I pack your 1300 version to the recovery. That is rock solid for me.3coutts - is there any chance you can shorten the filename somewhat?
...only the filename is so long now that I'm having problems telling versions apart when I download them ...the filenames get truncated sometimes such as in ROM Manager and clockwork...
I suggest perhaps removing the LeeDroid bit cos it's not really relevant anymore...I promise I'll put more attention into my file management if you can do this2Ok
Building CFS versions with -:
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_NS is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_CGROUP_BFQIO=y
# CONFIG_NET_CLS_CGROUP is not set
