[KERNEL] SpeedMod Froyo [K13E HPCall VoodooSnd7 SharpnessFix STABLE]

uppon2 · Nov 15, 2010

Hello. I am testing kernels for battery usage and I am now using Hardcores speedmod kernel i1_2-250hz-r2-CWM - All tweaks enabled - No lagfix

I would like to say that i was using i1.1-250hz for about a week but this new one is working much better for me.
I believe my phone has a very honest battery

harrydg · Nov 15, 2010

hardcore said:
Yes I have considered those compile options, and I think the current ones are the best for this CPU. The thing is, to really see if compile options make it better or worse, a lot of proper benchmarking has to be done.

If you are interested, you can check out the linked PDF file on the 1st post where there was some research done on it.

Also, according to that report (and I've read it a few times elsewhere), O3 is slower than O2 for the cortex-a8 CPU, and it makes the code bigger.

About the config options, it might not be a good idea to disable swap because it might break other things. I personally haven't tried, but because there are some pre-compiled modules where we don't have the source for, if we change the wrong thing then the kernel won't boot.

sorry to answer just now... do you have a list of modules that you don't have the sources for? plus: if you don't have the sources, how do you use them? are they "binary blobs" with stubs that you DO compile?
99.999% chance that removing swap support doesn't change a thing. It's just the way the linux kernel is built, or you (can) use swap, or you don't. Nothing else is impacted. So unless you have some binary-only memory management units, it won't make a difference. Can you put a kernel tree online somewhere, so that i can take a look at it? (incl the precompiled modules?) I can't connect to many sites here, so a tar.gz with everything in it would be perfect! (if you find the time

)

Thanks in advance (again

)
ps. I looked at the PDF you put on the first page, but haven't had time to fully read it all..

Fihlvein · Nov 15, 2010

Update on my situation. Ultimately did factory format (*2767*3855#) which resulted to booting forever without presenting login screen.

Now going to reflash with Odin.

Gasp, luckily I took backup on Saturday. I still don't understand how this could happen. What made CWM recovery to suddenly find changed config file?!

Well of course, unstable is unstable.

harrydg · Nov 15, 2010

zroice said:
hey again guys.. sorry for another noob™ question:

What does the kernel sharpness/granuality affect? Or how "should" it affect the phone?

From what I've read so far it affects smoothness and battery life if you just look at user experience.. but how is it affected?

Higher HZ -> smoother but less battery?
Lower HZ - choppier but longer battery?

What exactly does this do anyway? I tried google but couldnt find a good answer.

--- Ohh and while I'm at it... how do the lagfixes and/or tweaks affect battery life?

No:
higher HZ -> more responsive, but more process switches, so applications (may) run slower, and slight battery impact may be possible
lower HZ -> longer timeslices, so longer "wait" for process to get cpu time. Applications get bigger timeslices, so faster to finish and less process switches, so might slightly improve battery life.

The only question now is: is this "battery life" relevant... or are we talking about 0,001% for a 100HZ -> 500HZ (mind you, HZ has NOTHING to do with Hz (Hertz)... well ,it does, but ... no it doesn't! it's completely different

)

As always: every change in behaviour has impact on battery life... but how (positive/negative) is very hard to quantify. Actually, the ONLY way to measure this, is to put a (very sensitive) ampere meter between your battery and your sgs and measure the current...

lelf · Nov 15, 2010

hi guys!!! i have change my bootanimation and all work well. But im asking if is possible to change the bootanimation when i shutdown my phone

harrydg · Nov 15, 2010

battery statistics

People ,

may i have your attention please!!
Can you all take a look at the battery discharge graphs on the following site:
http://www.mpoweruk.com/performance.htm
(maybe read it ALL)
after that, read this:
http://www.mpoweruk.com/soc.htm

This will show you that all your "100-99 is very good" and other crap... is completely USELESS! Learn first how it works, what batteries do, how they work (just a little bit, the basics).
That way, we can have an "adult" conversation with USEFUL information with which we can work. so PLEASE PLEASE PLEASE... read these pages thoroughly!

Thanks in advance for your cooperation, all!

Qazz~ · Nov 15, 2010

1~2% battery depletion per night is the norm for me with this kernel

PombeirP · Nov 15, 2010

harrydg said:
People ,

may i have your attention please!!
Can you all take a look at the battery discharge graphs on the following site:
http://www.mpoweruk.com/performance.htm
(maybe read it ALL)
after that, read this:
http://www.mpoweruk.com/soc.htm

This will show you that all your "100-99 is very good" and other crap... is completely USELESS! Learn first how it works, what batteries do, how they work (just a little bit, the basics).
That way, we can have an "adult" conversation with USEFUL information with which we can work. so PLEASE PLEASE PLEASE... read these pages thoroughly!

Thanks in advance for your cooperation, all!

+1!

10 chars

SysTem-X · Nov 15, 2010

lelf said:
hi guys!!! i have change my bootanimation and all work well. But im asking if is possible to change the bootanimation when i shutdown my phone

Yes its possible, the forums has mentioned it.. search please!

bilboa1 · Nov 15, 2010

harrydg said:
People ,

The "%" in the battery is not necessarily reflecting the real discharge curve, actually it probably doesn't.. :/
All we can do is get a "good feeling" of how many % have been used, using the same rom (aka JPA/JPO based)
Otherwise we could use the direct "mah" report from the kernel, It's probably in /proc (someone going to flame cause I'm not using capitals, oh well!

) - probably not super accurate, but more than the %

hardcore · Nov 15, 2010

Good news guys. As we know the biggest user of battery is the 3G radio. I've found a way to disable HSPA (leaving 3G only), which should give us better battery life.

http://xdaforums.com/showthread.php?t=837716

Its off-topic from this one, so please continue radio-related battery life discussions on that thread.

harrydg · Nov 15, 2010

compiling arguments...

Here I am again.. *****in' about stuff

but this is what i found:

-fno-gcse remove (completely disabling GCSE which actually causes performance loss on this test suite)
-farm-fix-gcse-loop-hierarchy (add if possible)
-farm-fix-gcse (add if possible)

==> if these fixes aren't in gcc (yet), then adding -no-gcse is (for the moment) better anyway

-fprefetch-loop-arrays (best performance with this macro on Cortex-A8 is achieved with no prefetching instruction at all and with unrolling factor equal to 4)
--param l2-cache-size=512
--param l1-cache-size=64
--param simultaneous-prefetches=6
--param prefetch-latency=400
--param l1-cache-line-size=32 (the best value found for l1-cache-line-size is 32, though ARM documentation specifies line size equal to 64)
-mvectorize-with-neon-quad (option gives slightly better overall results)
After enabling autovectorizer (-ftree-vectorize -mfpu=neon -mfloat-abi=softfp), we were surprized to observe performance regression.
We have chosen -O2 as the base, since our tests have shown that -O2 outperforms -O3 on expedite by 0.5-1%

Small thing to added:
If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=`neon'), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.
==> this makes me think: how "needed" is the floating point precision in calculations? (as in: it's not always "less precise")
What worries me on the NEON extension is also the following:
"First, we have analyzed why so few loops (just about 25%) were vectorized
automatically by GCC. Most common causes of autovectorizer's failure were
the following: function calls within the loop body (mostly indirect calls, so they
can not be inlined), switch operator within a loop, and unsupported operations
(e.g. there is no support for vector division on NEON). It's worth to note that
switch operators within loops in libevas are used to specialize two cases for
transparency values 0 and 1, so a multiplication by alpha-channel value could
be replaced with simple copy of either source or destination color value. Though
such specialization prevents the loop from being vectorized for NEON, pure
ARM specialized code still signicantly outperforms autovectorized NEON code
on expedite tests."

Is there anyone who has access to this?:
ARM RealView Development Suite (RVDS)

I'd like to test compile the kernel on the compiler created by ARM itself... it is supposed to be A LOT faster than gcc... but the only caveat might be that the linux kernel is "written to be compiled with gcc"
but it's worth testing if someone has access

dupel · Nov 15, 2010

harrydg said:
Here I am again.. *****in' about stuff
but this is what i found:

Impressive!

@hardcore - raspdeep in his latest kernel fixed init.d support in universal lagfix. Any chance we can have it here too (fixed init.d)?

hardcore · Nov 15, 2010

harrydg said:
Here I am again.. *****in' about stuff
but this is what i found:

-fno-gcse remove (completely disabling GCSE which actually causes performance loss on this test suite)
-farm-fix-gcse-loop-hierarchy (add if possible)
-farm-fix-gcse (add if possible)

==> if these fixes aren't in gcc (yet), then adding -no-gcse is (for the moment) better anyway

-fprefetch-loop-arrays (best performance with this macro on Cortex-A8 is achieved with no prefetching instruction at all and with unrolling factor equal to 4)
--param l2-cache-size=512
--param l1-cache-size=64
--param simultaneous-prefetches=6
--param prefetch-latency=400
--param l1-cache-line-size=32 (the best value found for l1-cache-line-size is 32, though ARM documentation specifies line size equal to 64)
-mvectorize-with-neon-quad (option gives slightly better overall results)
After enabling autovectorizer (-ftree-vectorize -mfpu=neon -mfloat-abi=softfp), we were surprized to observe performance regression.
We have chosen -O2 as the base, since our tests have shown that -O2 outperforms -O3 on expedite by 0.5-1%

Yes, this is how I reached the settings that are used for this kernel. As you can see, bigger numbers aren't always better (O3 vs O2).

Laum · Nov 15, 2010

dupel said:
Impressive!

@hardcore - raspdeep in his latest kernel fixed init.d support in universal lagfix. Any chance we can have it here too (fixed init.d)?

Err, Universal lagfix init.d works without any mods. All scripts just need S as the first character in the file name.

dupel · Nov 15, 2010

Laum said:
Err, Universal lagfix init.d works without any mods. All scripts just need S as the first character in the file name.

nope it doesnt. Quite a couple pages ago I with several people help couldn't make it work in any way.

At least it has some bugs since it didnt work for me and raspdeep fixed something.

Laum · Nov 15, 2010

dupel said:
nope it doesnt. Quite a couple pages ago I with several people help couldn't make it work in any way.

At least it has some bugs since it didnt work for me and raspdeep fixed something.

Ah ok, strange that my scripts seem to be working just fine with S in front of them.

/system/user.log states correct output for the scripts. All placed in system/etc/init.d

And this is with Hardcore kernel version k2r2 200HZ.

dupel · Nov 15, 2010

Laum said:
Ah ok, strange that my scripts seem to be working just fine with S in front of them.

/system/user.log states correct output for the scripts. All placed in system/etc/init.d

And this is with Hardcore kernel version k2r2 200HZ.

Mind posting one of your scripts? I tried to make to work script from hardcores thread about optimal mount points (add nobh) but it refused to work in any way I tried it.

harrydg · Nov 15, 2010

hardcore said:
Yes, this is how I reached the settings that are used for this kernel. As you can see, bigger numbers aren't always better (O3 vs O2).

yeah, that's why i propose these changes to your compile options (as test of course):
--param l1-cache-line-size=32 (instead of 64)
-mvectorize-with-neon-quad
maybe all with marginal/no benefit, but you never know

hardcore · Nov 15, 2010

harrydg said:
yeah, that's why i propose these changes to your compile options (as test of course):
--param l1-cache-line-size=32 (instead of 64)
-mvectorize-with-neon-quad
maybe all with marginal/no benefit, but you never know

The 2nd option doesn't exist in the gcc that we use.
And the 1st option was chosen based on the inputs of that test, where they shared 2 sets of similar options but said that the second set (with 64 which I used) gave overall better results.

Moreover, it probably will be quite impossible for us to actually benchmark the difference, unless we have the time & resources of those researchers! But I appreciate you taking the time to understand the options and suggest changes.

[KERNEL] SpeedMod Froyo [K13E HPCall VoodooSnd7 SharpnessFix STABLE]

Inactive Recognized Contributor

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts