Reduce Android Lag

Any negative effect on the battery?

I'd to try it on my Galaxy S too
 
AlphaJohn said:
Seeing that my phone normally last 4 days you will have to wait some more before I can comment :)
Click to expand...

What?! You have a Razr MAXX-super-duper-extra-battery-pack-edition? ;)

Hah, I'll just install it now. Was planning on flashing the new CM10 update anyways :)
 
Looks like this is a sham:

Contrary to what many may think, what we report on is not always perfect. While we get many things right and have a great group of developers who continually stretch devices to heights, sometimes we highlight solutions with unknown gains. A recent article we published on a hack for gaming on the Nexus 7 and other devices is one such example.

The premise of the hack is that you can reduce lag by keeping a section of the Android file system (/dev/random) full of random bits so that the system does not have to wait for the file system to generate them. In theory that sounds great, and has shown some success in certain areas where lag was obvious, but it presents all sorts of other problems.

It is for those concerns that we do not recommend using this fix. The fix itself in no way causes harm, and is near-placebo in its effects. CyanogenMod developer arcee posted information on the fix, stating that

The only users of /dev/random are libcrypto (used for cryptographic operations like SSL connections, ssh key generation, and so on), wpa_supplicant/hostapd (to generate WEP/WPA keys while in AP mode), and the libraries that generate random partition IDs when you do an ext2/3/4 format. None of those 3 users are in the path of app execution, so feeding random from urandom does nothing except make random… well… less random

There are valid concerns about lag and how the Android OS handles them, and there is discussion currently ongoing within the Android Code about this, but this fix does not address those issues and instead gives performance gains through boosting CPU speed. The developer himself stated that this could in effect reduce battery life, since the hack is waking the CPU every second.

As is always the case, anything you use here on XDA is done at your own risk, and you assume all liability for your actions. That said, there are times we pass on inaccurate information, and this is one of those times. We do applaud all of our developers for working to find fixes for the things that nag at them. However, we jumped the gun on this, without letting adequate discussion and testing take place.
Click to expand...
 
Maverick Jester said:
Looks like this is a sham:
Click to expand...

Do not be so quick to call it one:

I poked at this a bit more and I think people are being too quick to
dismiss this. Lets look at the flow of data. The kernel takes events
for ARM mostly input but also block device activity to fill entropy
pools. These entropy pools are then available to both userspace as
/dev/random, and /dev/urandom, as well as to certain in kernel devices
and libraries. I do include /dev/urandom because it first attempts to
get its randomness from the same entropy pools as /dev/random.
/dev/urandom is less secure because it will give out less random data
instead of blocking, however it will deplete most of the secure entropy
first.

Now /dev/urandom has depleted all the "stored" entropy it needs to go
through the process of generating it's own. On ARM we use the slowest
possible method software, instead of x86 that has arch specific
randomness hooks. Each of these steps is wrapped in a spinlock, and in
certain circumstance preemption is disabled, so if we have multiple
calls happening we are going to get some lock contention. This is one
possible slow down.

We now have a depleted entropy pool, so the kernel needs more random
bits. Now every input event is used to try to generate randomness which
kicks in preemption being disabled while we run get_cycles and
mix_pool_bytes, which it turns out we generally don't even use. The
input events are so close together and we take the minimum delta that
usually we do all this work and then don't use the end result.

Because we are throwing out most the events the generate randomness
our pool is hovering at less than 300 bytes so we are constantly running
these checks on input trying to find randomness.

The use of rngd is actually allowing the kernel to hit a codepath
where it breaks out of this loop and not deal with generating more
random bits. Basically it is taking away less overhead from our input
event which still needs to be acted upon by userspace. I don't have the
numbers to back it up yet, and I don't think this is some silver
bullet, but there may be some truth to this fix.

We are doing a lot of "extra" stuff all wrapped inside locks for each
input event. This could be a serious source of input interactivity and
latency. (John Nett)
Click to expand...
 
AlphaJohn said:
Do not be so quick to call it one:
Click to expand...

From the xda article:

The only users of /dev/random are libcrypto (used for cryptographic operations like SSL connections, ssh key generation, and so on), wpa_supplicant/hostapd (to generate WEP/WPA keys while in AP mode), and the libraries that generate random partition IDs when you do an ext2/3/4 format. None of those 3 users are in the path of app execution, so feeding random from urandom does nothing except make random… well… less random
Click to expand...

Not me that's calling it a sham, xda is... FWIW, I saw no improvement using it on my device (S2, running Resurrection Remix 3.1.3), but I did see what many others saw- increased battery usage.
 
Maverick Jester said:
.... Snip... but I did see what many others saw- increased battery usage.
Click to expand...

Hmmm... I never saw that in the article (skim read it).
My battery was around 3.5 to 4.5% per hour drain (everything switched on permanently). The last few days it has dropped to below 3% per hour. Currently at 2.8% per hour. Seems to just last forever.

Not sure if it was this that changed things or not though.
 
Maverick Jester said:
From the xda article:



Not me that's calling it a sham, xda is... FWIW, I saw no improvement using it on my device (S2, running Resurrection Remix 3.1.3), but I did see what many others saw- increased battery usage.
Click to expand...

My battery life if anything has gotten slightly better. And i am using my phone more (Especially browsing) as it has made quite a big difference when using Chrome.
 
The_Unnamed said:
My battery life if anything has gotten slightly better. And i am using my phone more (Especially browsing) as it has made quite a big difference when using Chrome.
Click to expand...

I thought so too initially, then ran a few tests and realised that with it on or not, the speed in Maps and the browser didn't really get faster. DroidWall was more the issue than anything... But if it works for you, that is pretty awesome.

I do think that it is most likely dependant on the ROM base and model that you are using.
 
I tried it on my Nexus 4... no difference there... then I follow Chainfires (XDA genius) tweets, and he also does not find any noticeable difference on his devices at current... so I think for newer devices on JB roms, its not going to do much, if anything...
 
SirFooK'nG said:
I tried it on my Nexus 4... no difference there... then I follow Chainfires (XDA genius) tweets, and he also does not find any noticeable difference on his devices at current... so I think for newer devices on JB roms, its not going to do much, if anything...
Click to expand...

I agree with this.

I am running a 4.2 based ROM on my S2 and saw no improvement at all when using the Seeder. Might flash the JB test ROM and compare, just for kicks...
 
I haven't experienced a depreciation in battery life. And it feels - well - I haven't benchmarked at all so it's difficult to quantify - but feels pretty smooth since installing it on the SGS. This phone always seemed just sliiiiightly too slow to run ICS apps very well, but it doesn't feel like that's the case now.
 
I think what would be interesting in terms of the differing results experienced here, would be to state the phone model and Android version being used.

Example:
Model: Galaxy S2
Android version: 4.2.1
No difference experienced.

Use it, don't use it...
 
I haven't noticed much of a difference, except it seems my battery isn't lasting as long.
SG i9000, CM10.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X