maemo.org - Talk - Timer programming, battery consumption

maemo.org - Talk (https://talk.maemo.org/index.php)

- Development (https://talk.maemo.org/forumdisplay.php?f=13)

- - Timer programming, battery consumption (https://talk.maemo.org/showthread.php?t=59290)

Timer programming, battery consumption

Hello. I'm looking into writing an application to send the accelerometer information over a bluetooth connection, to feed the information from the n900 into my laptop. Now the problem I'm faced with is when i read the information from the accelerometer i'll have to update is every so often i.e. read it every 100ms, then after every 100ms send the information over bluetooth. Now constantly updating information every so often, would that start to drain the battery quickly?

Also at the same time I'm thinking even if it would start to drain the battery to begin with, as using timers only use processor tick's, so my code will only execute when the processing ticks rollover.

Re: Timer programming, battery consumption

If you use usleep() to halt execution (and not a busy wait), the big hog on your battery will be the BT connection.

One way to save energy would be to send more information than one sample at a time. If you need real time updates, this is of course not an option.

Re: Timer programming, battery consumption

Cheers for your reply. Yea i'll be wanting real time updates, but my main concern is avoiding infinite loops or big loops as much as possible.

The problem i think about using usleep is that it'll halt execution for a period of time, but i will require the function to re-execute after a period of time. I can achieve what i want with loops, but as we all know it's nasty to do so.

Re: Timer programming, battery consumption

Actually the CPU doesn't tick at all if there are no timers about to expire.

When the time to the next timer firing gets large enough, the CPU clocks and voltage are switched off, completely halting the CPU and dropping power consumption of CPU to near-zero. The RAM is kept alive, and the CPU eventually gets woken up by an external timer or external IRQ, to process whatever app requested to be woken up..

So yes, if you have a timer that fires every 100ms, there will be a significant impact on standby battery life. XChat used to have a periodical 1-second timer (IIRC), and when the maintainer managed to get rid of it, battery life improved significantly for me :-)

Re: Timer programming, battery consumption

Quote:

Originally Posted by phil128 (Post 767210)

I'm not sure if I follow your reasoning here.

Code:

while(1) {

  get_and_send_sample();



  usleep(DELAY);

}

Why is this bad? If all you want to do is this, a loop is the easy and straight forward way to do it. If the application on the N900 is running a GUI, use a timer in GTK+/Qt instead.

A process that uses usleep will not be scheduled at all until enough time has passed which, I assume, is your goal.

Re: Timer programming, battery consumption

Quote:

Originally Posted by shadowjk (Post 767584)

This makes no sense. With 150+ processes running on your device, you will have some process running in the CPU at almost all time.

The kernel doesn't stop, hence the CPU can't halt. Device drivers rely on the continuous flow of timing ticks in the kernel.

Re: Timer programming, battery consumption

Quote:

Originally Posted by Joorin (Post 767730)

Code:

The tickless kernel feature (CONFIG_NO_HZ) enables 'on-demand' timer 

interrupts: if there is no timer to be expired for say 1.5 seconds when 

the system goes idle, then the system will stay totally idle for 1.5 

seconds. This should bring cooler CPUs and power savings: on our (x86) 

testboxes we have measured the effective IRQ rate to go from HZ to 1-2 

timer interrupts per second.

http://http://kerneltrap.org/node/6750

The kernel isn't a constantly running process. Kernel code only runs if there's something that jumps into kernel, like a hardware interrupt or a software interrupt (syscall).

You can for example use powertop to check this out yourself:

Code:

C#      | Ratio  | Avg/dura | Frequency | Ratio

--------+--------+----------+-----------+--------+

     C0 |  10.0% |          |   600 MHz |   9.5% |

     C1 |   0.2% |    0.3ms |   550 MHz |   0.0% |

     C2 |  12.1% |    2.5ms |   500 MHz |  11.7% |

     C3 |  26.6% |  101.2ms |   250 MHz |  78.8% |

     C4 |  51.0% |  528.4ms |

C0 is the only state where the CPU is actually running. C4 is deepest sleep state, with even voltage to the CPU cut off. It takes the longest time to reach and exit C4, so it's only entered if it's a long time until next wakeup.

Here you can see that during the 30second sample interval, when my N900 was in my pocket, running a script (5 second timer) and xchat (woken up by chat traffic only), my N900's CPU was completely off 51% of the time.
The average time in deep sleep was half a second at a time.
When my N900's CPU was on, 10% of the time, it spent 78.8% at 250MHz.

We also get a list of IRQs, and list of processes that caused wakeups. In my case the top was kernel, mmc, wireless.

Power domain shows statistics about the individual parts of the SOC:

Code:

Power domain activity breakdown

Domain  | % of time spent in states

--------+---------+---------+---------+---------+----------

usbhost |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

    sgx |OFF:  96%|RET:   0%|INA:   0%| ON:   3%| now:(OFF)

    per |OFF:  75%|RET:  13%|INA:   0%| ON:  10%| now:(ON)

    dss |OFF:  92%|RET:   0%|INA:   0%| ON:   7%| now:(ON)

    cam |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

   core |OFF:  50%|RET:  24%|INA:   3%| ON:  21%| now:(ON)

   neon |OFF:  50%|RET:  26%|INA:  11%| ON:  10%| now:(ON)

    mpu |OFF:  50%|RET:  26%|INA:  11%| ON:  10%| now:(ON)

   iva2 |OFF: 100%|RET:   0%|INA:   0%| ON:   0%| now:(OFF)

sgx: 3D accelerator
per: peripherals.. mmc and so on
dss: display subsystem. framebuffer and signal generator for the lcd
cam: camera
core: CPU Core
neon: The neon unit of the CPU
mpu: memory protection unit
iva2: video decode acceleration unit

OFF: Completely off
RET: powersaving mode
INA: On, but Inactive

As a sidenote, both intel and the QT folks are working on synchronizing timers in MeeGo. That is, the app can request a wakeup with specified precision (or lack thereof). Say you want your app to wake up every 10 second, but you don't care that much about exactly 10 second. So you can ask "10 seconds, give or take a few", and the kernel or qt can look for another app that has a similar requirements, and slowly move their timers closer together until they fire at the same time, effectively coalescing the wakeups of two apps into becoming a single wakeup.

It's much more efficient to do a alot of work at highest CPU speed, so the CPU can quickly go back to sleep, and sleep for a long time.

Re: Timer programming, battery consumption

I do believe that accelerometer sends you events, i.e. you don't make code where you sleep and the request the values. You register to listen those events and receive the updates. To be honest I don't know, but e.g. GPS works like this.

Re: Timer programming, battery consumption

Hi. I know you can read the information from the accelerometer from within user-mode via the proc file system. So all i'm gonna do is constantly read and close from this file and send the data over. Hopefully the bluetooth communication stays consistant.

The reason i don't really wanna code up an endless loop was due to a lecture slide from the stanford university where it states "don't use big loops, use timers etc" I assume due to its more efficient. At the same time i guess it i want to transmit data in real-time i guess i have no choice but to use and endless loop to cycle through reading from the proc filesystem(accelerometer) and transmit this over bluetooth.

Re: Timer programming, battery consumption

@shadowjk

I didn't know about the tickless kernel feature. Thank you for pointing it out.

How will device drivers, for example, keep track of time? Will all device drivers have to be interrupt driven for this to work as intended?

Or will all timing be bound to one execution cycle in the kernel?