Cinder Mobile OS Lets Users Send More Power To Slow Apps

alphadogg writes with this excerpt from Network World: "Stanford University researchers are designing an operating system from the ground up to handle the power and security requirements of mobile devices. The Cinder operating system is already working on an Arm chip, and members of the team are working on making it run on the HTC G1 handset, according to Philip Levis, a Stanford assistant professor. Levis spoke about Cinder at the Stanford Computer Forum on Tuesday. If an application isn't running as fast as the user wants, a Cinder-based phone could include a button to boost the energy allocated to that application, Levis said. Cinder also could allow users to download any code and run it safely on their phones in a 'sandbox' mode."

Comments

Warning:

[Anonymous Coward]

If you over-amp a sandboxed app too much, you end up with molten glass.

Umm

[Jurily]

include a button to boost the energy allocated to that application

I thought the chip gets the power, not the application. Am I reading this right?

Re:Umm

[jonbryce]

Is it like the Turbo button you used to get on ancient desktop computers?

Re:Umm

[sakdoctor]

Those who don't understand the TURBO BUTTON are condemned to reinvent it, poorly.

Re:Umm

[Nutria]

I thought the chip gets the power, not the application. Am I reading this right?

Remember that tech "journalists" are usually clueless fools, so reality may be way different than what's in the article.

I'm thinking more that it might be like the Turbo button that PCs had in the semi-old days, when CPU speeds were in the 5-16MHz range. Of course, I haven't RTFA...

Re:Umm

[causality]

include a button to boost the energy allocated to that application

I thought the chip gets the power, not the application. Am I reading this right?

The application is intangible, non-material information in the form of ones and zeroes. It's not possible to apply electrical power to it. Therefore, "more power to slow apps" or "boost the energy allocated to that application" should be understood as an expression meaning that there is more energy given to the chips/hardware that is running the application in question.

The article is very light on details, but I take it the idea is that more power would translate to higher clock frequencies or higher data throughput and the like. The article also fails to mention whether this mobile OS is capable of multitasking. If it is, then presumably the power settings for a given application would apply to the timeslices during which it is running.

Re:Umm

[Anonymous Coward]

Sounds like it, but it's not a bad idea - the processors used in phones are capable of running at a much higher speed. They don't normally because higher speed == more power, even at idle.

Re:Umm

[Jurily]

I'm thinking more that it might be like the Turbo button that PCs had in the semi-old days, when CPU speeds were in the 5-16MHz range.

The Turbo button slowed the CPU. And it was a good thing, because many applications used CPU speed for timing. You bought a new computer, and suddenly your favorite game ran too fast to be enjoyable.

Re:Umm

[Nutria]

The Turbo button slowed the CPU.

It was a toggle button, so it would slow or speed the CPU depending on it's state when you pushed the button. Of course, few wanted to run in "normal" speed unless they had to.

Now, it's the opposite. You want to run slowly, a often as you can, to preserve battery charge. But the "turbo button" moniker still applies.

Re:Umm

[MBCook]

Of course, few wanted to run in "normal" speed unless they had to.

But isn't this the problem with this idea? Users will just hit the "turbo" button all the time because non-instantaneous is too slow. This both defeats the purpose (since everything will run at turbo) and will annoy the user (when "turbo" isn't fast enough).

Isn't spending 20k cycles at full power and then dropping back to next-to-no-power during idle sometimes more efficient than spending 20k cycles at 20% power (which has to run 5x as long)?

Wouldn't it simply be better to make a little indicator icon of how much power is being used at a instant (happy battery / busy battery / battery on treadmill / battery playing Sisyphus)? Then users could see which apps use too much power (3D games, audio analysis, lots of stupid animation) and which use little (crossword puzzle) so they could adjust their behavior and/or try to get developers to improve the applications that are needlessly wasteful?

Re:Umm

[Anonymous Coward]

Ah, but OS's traditionally don't limit the processing power available to a task if the processor would otherwise be available - I think the difference here is that scheduler stops a process consuming more than (say) 1/10 of the CPU even if that means the CPU is idle 8/10 of the time; because the user would rather keep 8/10 reserved to make the battery last longer.

Enegry consumed by an application really means 'enegry consumed by the system as a whole because it is running that particular application.' Clamping the run-time of an application should clamp the enegry consumption of that application.

Re:Umm

[K. S. Kyosuke]

Uhm, that was supposed to contain a link.

Geek Phone?

[Manip]

... So you know what people say about academics being out-of-touch? ...

This article is the perfect example of that. The fact that they think any real person will use or understand a "sandbox mode" is just laughable.

The power boost button is just offloading what the OS should be doing behind the scenes onto the user to rarely get used by most of its users.

Security is insanely easy to solve on a phone...
1) Build a Java VM for 3rd party Apps
2) Limit its API scope
3) Win.

Re:Geek Phone?

[cigawoot]

Ain't this the apple approach? Build an OS, limit 3d party access to the API. Of course, minus the app store.

Re:Geek Phone?

[tomhudson]

Way to miss the point :-) The GP poster claimed that macs were the exclusive purview of geeks. My point was that non-geeks like them too, not that ONLY non-geeks like them.

After my wife played with my computer for a few weeks, she wanted a Macbook. I'm pretty happy with it, too. She's dumb as a brick,

Oh man, what a set-up line ... please check all that apply ...

[_] My wife is SO dumb, she married ME!
[_] I am SO dumb that I married someone dumb as a brick!
[_] Blow-up dolls ARE as dumb as a brick, you ignorant clod!
[_] In Soviet Russia, dumb wife bricks YOU!
[_] My wife is SO dumb, she's the CowboyNeal option!
[_] My wife is SO dumb, she once burned water.
[_] My wife is SO dumb, she lost the recipe for ice cubes.
[_] My wife is SO dumb, she chases after cars.
[_] My wife is SO dumb, she buried her father in a rented suit, and has been paying $50/month for years
[_] My wife is SO dumb, she complains that when I die, she doesn't know HOW she's going to keep paying my life insurance policy.
[_] My wife is SO dumb, when she won the lottery, she returned the ticket and insisted on another one because it didn't have "her" numbers on it.

The real one ...

[X] My wife is so smart, she conned me into buying her a mac.

Have a nice day :-)

Battery life?

[jason4567]

It seems to me that running anything at a higher speed will kill the battery life. There are almost no reasons to do this anyway, since things are already fast enough on an iPhone or Android based systems already.

see renice(1) manpage

[bughouse26]

RENICE(1) BSD General Commands Manual RENICE(1)

NAME
          renice - alter priority of running processes ...
DESCRIPTION
          Renice alters the scheduling priority of one or more running processes. The following who parameters are interpreted as process ID's, process
          group ID's, or user names. Renice'ing a process group causes all processes in the process group to have their scheduling priority altered.
          Renice'ing a user causes all processes owned by the user to have their scheduling priority altered. By default, the processes to be affected
          are specified by their process ID's. ...

nice java

[Doc Ruby]

I don't see why these "cinder" features can't be delivered by realtime UI to nice and with a Java sandbox. In other words, Android or any other Linux phoneOS, with a little tweak wiring top to nice, and a Java VM. App running slow, crank out the "nice" level, and it will suck more juice as it runs faster than the other apps left out of the juice rotation. Put the UI in terms of power instead of CPU, and you're groovy.