> This is all fascinating, and I'm not totally dismissing that something is happening here.
Qualcomm devices have a hardware random device, which when coupled with the qrngd daemon feeds the kernel entropy pool. In normal operation of Android, I never see this pool actually get low unless running the qrngtest tool, in which case qrngd just fills it right back up.
Looking in drivers/char/random.c though, the functions which are called in the interrupt, input, and block device paths have an inner function add_timer_randomness which calls preempt_disable().
As a totally non scientific test, I turned all of these functions into no-ops and recompiled. This way, we're ONLY relying on the hardware RNG.
There's no change in entropy available because random numbers really just aren't being used all that often.
But now, I'm seeing a modest increase in interactivity on the device. Certain things feel smoother, and there is less UI jank. There's no change in frequency scaling or power usage as proposed earlier. qrngtest passes just fine as well.
What's going on here? I'm not entirely sure. We're either all crazy, or this is tickling a subtle scheduling bug in the kernel. More investigation is needed. [1]
Nice to see somewhat knowledgable commenting on this issue and actually test things out. It's very easy to say "meh, you haven't done a scientific test so it's probably placebo", but remember that you're being equally un-scientific in such an analyse.
When so many users are reporting improvements you (aka. Google) owe them to get to the bottom of it.
I also find it surprisingly that nearly no-one posts information about what phone they tested it on. Android ships in so many variants that it wouldn't surprise me if it only works in some of them.
>It's very easy to say "meh, you haven't done a scientific test so it's probably placebo", but remember that you're being equally un-scientific in such an analyse.
No, dismissing unblinded observations of phenomena the perceptions of which are notoriously suggestible (like UI responsiveness) is not "equally un-scientific" as making unblinded observations of phenomena the perceptions of which are notoriously suggestible.
Pointing out that such observations is unreliable is, in fact, a simple application of science. Grandstanding tu quoque arguments are not.
I am running it on Nexus S running ICS and there is a definite improvement, in launching apps and getting back to home. I think the improvement is mostly seen on older devices, newer devices are already fast enough.
Ah, this is interesting, since he's probably one of the few people outside of Google with the credentials to actually comment on something like this. It still seems hard to quantify "UI jank" but I'm glad he's looking into it. I had dismissed it as placebo yesterday but if he thinks it's worth looking into then maybe it is.
Qualcomm devices have a hardware random device, which when coupled with the qrngd daemon feeds the kernel entropy pool. In normal operation of Android, I never see this pool actually get low unless running the qrngtest tool, in which case qrngd just fills it right back up.
Looking in drivers/char/random.c though, the functions which are called in the interrupt, input, and block device paths have an inner function add_timer_randomness which calls preempt_disable().
As a totally non scientific test, I turned all of these functions into no-ops and recompiled. This way, we're ONLY relying on the hardware RNG.
There's no change in entropy available because random numbers really just aren't being used all that often.
But now, I'm seeing a modest increase in interactivity on the device. Certain things feel smoother, and there is less UI jank. There's no change in frequency scaling or power usage as proposed earlier. qrngtest passes just fine as well.
What's going on here? I'm not entirely sure. We're either all crazy, or this is tickling a subtle scheduling bug in the kernel. More investigation is needed. [1]
[1] Steve Kondik (CyanogenMod maintainer) https://code.google.com/p/android/issues/detail?id=42265#c11...