Joachim recently mentioned that his GTA02 felt slow, and suspected excessive acceleration sensor activity to contribute to this.
I did a little test to verify this: - foreground task: dd if=/dev/zero bs=1024k count=100 | time md5sum - background task: wc </dev/input/event2 No neod. With default settings, the acceleration sensor produced about 100 interrupts per second. I turned off console output with echo 0 >/proc/sys/kernel/printk With the "wc" running, I got the following results for the foreground task: real 0m 19.67s user 0m 10.04s sys 0m 4.44s real 0m 19.96s user 0m 10.12s sys 0m 4.86s real 0m 19.88s user 0m 10.25s sys 0m 4.54s I compared with wall-clock time and didn't notice any significant difference. With "wc" stopped (and I verified that the kernel handled no more lis302dl interrupts), I got: real 0m 19.89s user 0m 10.28s sys 0m 4.97s real 0m 19.91s user 0m 10.31s sys 0m 4.87s real 0m 19.93s user 0m 10.58s sys 0m 4.72s So serving the acceleration sensor did not significantly slow down CPU-bound tasks. In fact, it seemed to make them a bit faster, but that may be just noise or scheduling artefacts. Oddly enough, during my testing, something switched the acceleration sensor to 400ksamples/s. Then the times became: real 0m 23.29s user 0m 10.68s sys 0m 6.03s real 0m 23.38s user 0m 10.79s sys 0m 5.84s real 0m 23.34s user 0m 10.87s sys 0m 5.84s So it seems that sampling the acceleration sensors at 400ksamples/s would produce a moderate slowdown, while running them at only 100 ksamples/s - even continuously - should be barely noticeable. - Werner
