Linked by Thom Holwerda on Wed 19th Apr 2017 20:36 UTC
Windows

Most people running Windows like having multiple apps running at the same time - and often, what's running in the background can drain your battery. In this latest Insider Preview build (Build 16176), we leveraged modern silicon capabilities to run background work in a power-efficient manner, thereby enhancing battery life significantly while still giving users access to powerful multitasking capabilities of Windows. With "Power Throttling", when background work is running, Windows places the CPU in its most energy efficient operating modes - work gets done, but the minimal possible battery is spent on that work.

My biggest worry with technology like this is that it affects unsaved work. Luckily, you're supposed to be able to turn it on and off.

Order by: Score:
Comment by tidux
by tidux on Wed 19th Apr 2017 22:46 UTC
tidux
Member since:
2011-08-13

This won't impact saved work - it's all about switching silicon to lower power states. At most, work will get done more slowly, but if it's like most background processes on Windows those are mostly idling anyways.

Reply Score: 3

RE: Comment by tidux
by Alfman on Wed 19th Apr 2017 23:58 UTC in reply to "Comment by tidux"
Alfman Member since:
2011-01-28

tidux,

This won't impact saved work - it's all about switching silicon to lower power states. At most, work will get done more slowly, but if it's like most background processes on Windows those are mostly idling anyways.


That's the thing that the article needs to clarify because "Most people running Windows like having multiple apps running at the same time - and often", while true, doesn't actually imply those background processes are using any CPU while in the background.

The article says "running in the background can drain your battery", which is also true of course, but it isn't clear what apps they're talking about since the vast majority of interactive apps don't use CPU in the background. A video/audio player can run in the background, but presumably the user would stop it if he didn't want that to happen and giving it less CPU than it needs would just make it jerky. A file transfer or encoding process should run in the background. So I guess it's a bit of a mystery what they are using to claim an "11% savings in CPU power...".

Their own screenshots display "microsoft edge" prominently in the task manager, is that possibly a clue that the MS edge browser wastes CPU in the background? I'm not really sure, does anyone know what kind of apps this is targeting?

Reply Score: 2

RE[2]: Comment by tidux
by Brendan on Thu 20th Apr 2017 06:16 UTC in reply to "RE: Comment by tidux"
Brendan Member since:
2005-11-16

Hi,

Their own screenshots display "microsoft edge" prominently in the task manager, is that possibly a clue that the MS edge browser wastes CPU in the background? I'm not really sure, does anyone know what kind of apps this is targeting?


No idea; but it all sounds extremely silly to me (especially the over-complex "detection" nonsense).

The Windows scheduler has priority classes (including "idle priority class" and "below normal priority class"), and if Microsoft weren't massive morons they'd throttle CPU speed whenever the only threads that are running are using these priority classes.

Mostly, it should've been a minor little tweak that was done 15 years ago.

- Brendan

Reply Score: 2

RE[3]: Comment by tidux
by grahamtriggs on Thu 20th Apr 2017 14:27 UTC in reply to "RE[2]: Comment by tidux"
grahamtriggs Member since:
2009-05-27

The priority classes are only going to work if the application detects whether it should be in an idle state, and changes it's priority.

Depending on user permissions, it may not be allowed to change it's priority.

Then you get all sorts of interesting cases - if a window is visible (e.g. it's the only 'application' running), but it doesn't have focus (user has clicked on the explorer, or dismissed an alert) - should that application consider itself a background application or not?

There is an argument that the application should be allowed to know best - but it's also a ton of effort for developers to be building such determination into everything they write.

Having something sensible in the OS that takes that burden from the application developer is a good thing, along with user controls to override if necessary. Possibly even better if there are APIs that let the application take control when the developer knows that is likely to be needed.

Reply Score: 1

RE[4]: Comment by tidux
by Brendan on Fri 21st Apr 2017 02:03 UTC in reply to "RE[3]: Comment by tidux"
Brendan Member since:
2005-11-16

Hi,

I'm not sure where to start here...

An application is not a thread, and the scheduler does not schedule applications. Most threads spend most of their time blocked waiting for something to happen and not running.

A well designed application will have a higher priority thread for "user interface" (its window/s), plus lower priority thread/s for any heavy processing and even lower priority thread/s for any background work. This ensures that the window is "responsive" (e.g. reacts to keyboard and mouse quickly) regardless of how much heavy processing or background work is going on. A higher priority thread for an application's "user interface" is almost always not running (only running for a small amount of time when the user presses a key or clicks the mouse).

When there are no threads running (all threads are blocked waiting for something) and CPU/s are idle, all modern schedulers reduce CPU power consumption, typically in "timed stages" (e.g. drop CPU speed a little after 1 second, drop it down more after 5 seconds, etc).

When the only threads that are running (not blocked waiting for something to happen) are low priority threads, you can drop CPU speed (after a time delay) early; and reduce CPU power consumption when low priority threads are running.

If an OS prevents a thread from reducing its priority for any reason (e.g. user permissions), that OS is a crippled piece of trash. Each thread should have a (potentially "user (mis)configurable") maximum priority and be able to change its current priority to any priority that is below that maximum whenever it likes.

- Brendan

Reply Score: 2

RE[3]: Comment by tidux
by avgalen on Fri 21st Apr 2017 11:13 UTC in reply to "RE[2]: Comment by tidux"
avgalen Member since:
2010-09-23

I completely agree, but as you probably know these CPU-priorities are rarely used. A lot of programs use threads that are running "in the background", but since they are running on the same CPU-priority as everything else they are competing for resources like everything else.

short analysis on my system:
Only 4 processes are running at low or below normal; 2 are related to Windows Search and 1 is the Windows Setting Synch. The other one is related to Chrome (7 other Chromes are running on normal)
Only 3 processes are running at high; the Window Manager and logon/startup

Reply Score: 2

RE[4]: Comment by tidux
by Alfman on Fri 21st Apr 2017 16:09 UTC in reply to "RE[3]: Comment by tidux"
Alfman Member since:
2011-01-28

avgalen,

I completely agree, but as you probably know these CPU-priorities are rarely used. A lot of programs use threads that are running "in the background", but since they are running on the same CPU-priority as everything else they are competing for resources like everything else.

short analysis on my system:
Only 4 processes are running at low or below normal; 2 are related to Windows Search and 1 is the Windows Setting Synch. The other one is related to Chrome (7 other Chromes are running on normal)
Only 3 processes are running at high; the Window Manager and logon/startup


That's a fair point, they may not set thread priorities optimally. However I agree with Brendan that it doesn't make a difference if the thread is blocking correctly on IO anyways. Even supposing threads were set to high or realtime priority, that shouldn't adversely increase power on an otherwise idle system. By far and large most background processes are 100% idle and therefor the CPU can (and does) throttle down.

So it still seems like an open question to me what kind of applications this is supposed to target.

We can throttle an application simply because it's using cpu in the background, but there's two potential issues with this:
1. This can adversely impact applications (like transcoding/file transfers/cdburning/music/video/etc) that are supposed to run in the background.

2. For units of work that require a fixed amount of CPU (either in the background or foreground), throttling can actually increase aggregate energy (because it requires more total time that the CPU has to stay awake for).

Edited 2017-04-21 16:19 UTC

Reply Score: 2

RE: Comment by tidux
by dukes on Thu 20th Apr 2017 15:06 UTC in reply to "Comment by tidux"
dukes Member since:
2005-07-06

This won't impact saved work - it's all about switching silicon to lower power states. At most, work will get done more slowly, but if it's like most background processes on Windows those are mostly idling anyways.


Ok, it won't impact saved work. But what about unsaved work?

Reply Score: 2

Throttling vs tombstoning
by avgalen on Fri 21st Apr 2017 11:21 UTC
avgalen
Member since:
2010-09-23

My biggest worry with technology like this is that it affects unsaved work.

As was mentioned by others, throttling only applies to CPU or processing of work.
tombstoning is a similar technique that applies to Memory so it COULD affect unsaved work (if things go wrong), but it is designed not to

Reply Score: 2