Coffeehouse Thread

1 post

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Low voltage & frequency background task offloading?

Back to Forum: Coffeehouse
  • User profile image
    androidi

    (Maybe all this has already been solved in WP in the way explained or otherwise, I haven't really looked)

    I read some press piece about saving iphone battery life by turning off the fitness background tracking thingy. Then I figured, well why would such thingy consume any noticeable battery amount if the amount of resources that needed amounted to some 80's home computer or less - isn't the problem really that if your ability to write sloppy code to a cpu that can boost to high frequencies is not limited, then the result is going to be higher battery use.

    I'm not sure if having some custom offloading processor is actually necessary, maybe the solution for background usage of the various sensors is simply having ability to run the background tasks with the primary cpu running at very low frequency so that the background tasks can collect data practically continuously without consuming much battery. I use similar approach on my old Pentium M laptop to run near-realtime data collection without setting off the noisy fans - I simply used the advanced power settings to force the cpu to never go above certain % of the max frequency.

    The way I see it, if there are multiple different background tasks of various natures, such as polling and realtime data capture (maybe you want to covertly record audio while not consuming any more battery than it really needs), then the battery saving problem boils down to making sure that expensive polling type behaviour is forcibly scheduled to not occur too often and various near-realtime/continuous types of data acquisition background activities should be each running the cpu only at frequency they really need - a further improvement would be to have low level/hardware based solution for capturing all the inputs and then have the app just specify a frequency at which they want to read the captured data/buffer.

     

    The benefit here is that this sort of possibly cpu intensive task would not be left to the average programmer but still enabled average programmer to create battery efficient realtime data acquisition solutions (essentially a gui for the low level capture functionality). Such low level functionality would probably have to use some sort of power efficient storage by itself if the capture produced lots of data, without needing to invoke the user written application to actually perform the saving of the data to disk. So when the user calls read data and save to disk API it would actually only copy or move the already saved pages to another location in the disk. (move would be similar to taking the captured data blocks in the 'page file' of the raw audio/video data and then assigning a filename to those blocks and putting some headers around them for later processing)

     

     

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.