Acceleration sensor: CPU load

Werner Almesberger werner at openmoko.org
Tue May 6 17:52:35 CEST 2008


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




More information about the openmoko-kernel mailing list