Dear all
I installed a USB selective suspend driver for web camera in Windows XP. And we can see the Intel CPU entering into C3 state in performance monitor tool. But after contrast test with unselective suspend driver, I found the time is almost the same to consume battery power in my notebook.
I think the correct result should be as the folloing:
The time is longger with selective suspend driver than unselective suspend driver.
right?
thank you
Hi,
How are you measuring power savings with selective suspend enabled driver ? i think it will be enough if you can confirm the device enters suspended state after your specified idle time. is your device entering suspended state after idle time ? doesnt that automatically indicate power saved ?
rtshiva
Yes, I found INTEL cpu enter into C3 state, and our device current changed to almost 0.06 mA after specified idle time.
I measure the power savings by computing the time from battery full state to enter XP auto sleep state (almost 5% power remainning).
thanks
first of all , i dont think such a measurment is valid to see power usage of
a single device.
Why are you mentioning the CPU power state as well ? isnt selective suspend
supposed to be triggered when your device is idle, so it doesnt matter what
state the CPU or other USB devices are in. Only your device should be
suspended after idle time. If your device enters suspend state in such a
scenario then it has done its part in saving power.
rtshiva
On Tue, Jul 14, 2009 at 10:50 AM, wrote:
> Yes, I found INTEL cpu enter into C3 state, and our device current changed
> to almost 0.06 mA after specified idle time.
>
> I measure the power savings by computing the time from battery full state
> to enter XP auto sleep state (almost 5% power remainning).
>
> thanks
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Dear rtshiva
I have monitored the CPU state using INTEL C7 tool, I have found it entering into C3 state( intel CPU working state is C0).
But, I think in same environment, the elapsed time should be longer with selective suspend driver.
Why there is no improvement on saving power?
denny
I also doubt the measurement you are using. What a device driver can do is
to enter the right power state when system want. The system power
consumption is managed by system. As you said, XP ‘almost’ auto sleep at the
same time, how much more time do you think a 0.06mA device can let system
work with battery from 100% - 5%?
thanks
wayne
denny,
it seems to me that you are suspending the whole system or i can come to
only that conclusion when you are refering CPU state when you are talking
about selective suspend. Selective suspend is when the device alone is in
suspended state while the CPU and the rest of the system is still running.
Regarding the method to measure power usage, i havent done any experiments
on my device with selective suspend enabled. Others in the list might be
helpful on that 
. A single USB powered device will not show major
difference in power consumption (at least thats what i think)
rtshiva
On Tue, Jul 14, 2009 at 1:22 PM, wrote:
> Dear rtshiva
> I have monitored the CPU state using INTEL C7 tool, I have found it
> entering into C3 state( intel CPU working state is C0).
> But, I think in same environment, the elapsed time should be longer with
> selective suspend driver.
> Why there is no improvement on saving power?
>
> denny
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Wayne Gong wrote:
…how much more time do you think a 0.06mA device can let
system work with battery from 100% - 5%?
Savings on the host side can be much bigger than on the device.
When the host controller can stop polling the bus,
CPU can enter higher C states, RAM interface consumes less too, and so
on. This is the real motivation to use SS. Unfortunately WinXP doesn’t
handle it well.
–pa
My understanding (from someone who attempted this not long ago) is that
Selective Suspend doesn’t actually work. Apparently for it to work, every
device on the hub must also implement SS. This means every USB device that
is plugged into your machine. According to my source, Microsoft
acknowledged that (a) this is a bug and (b) it will not be fixed. But I
don’t know if that meant (b) will never be fixed or (b) will not be fixed in
the current releases but will be fixed in a future release.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, July 13, 2009 11:51 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] usb slective suspend driver don’t save power
Dear all
I installed a USB selective suspend driver for web camera in Windows XP.
And we can see the Intel CPU entering into C3 state in performance monitor
tool. But after contrast test with unselective suspend driver, I found the
time is almost the same to consume battery power in my notebook.
I think the correct result should be as the folloing:
The time is longger with selective suspend driver than unselective suspend
driver.
right?
thank you
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Joseph M. Newcomer wrote:
My understanding (from someone who attempted this not long
ago) is that Selective Suspend doesn’t actually work. Apparently
for it to work, every device on the hub must also implement SS.
This means every USB device that is plugged into your machine.
According to my source, Microsoft acknowledged that (a) this is
a bug and (b) it will not be fixed.
I bet Michal Vodicka can shed some light here…
huaping jiang wrote:
Yes, I found INTEL cpu enter into C3 state, and our device current
changed to almost 0.06 mA after specified idle time.
What was your current draw before the device went into idle?
I differ on whether this means selective suspend “doesn’t actually work” but it is true that the entire hub has to be powered down before any single device can be powered down.
Also, note that there are some revisions of common chips that do not “selective suspend” properly, and continue to draw too much current. Check your chip rev and errata.
Peter
OSR
let’s clarify a couple of things
the amount of current drawn from a usb device on the usb wire is tiny compared to the amount of power you can save if you can put the processor into a low C state. Bus master traffic keeps the processor in C0 to maintain cache coherency (e.g. it must snoop), running the usb schedule causes bus master traffic. note that the schedule itself must be off, but the devices can remain on as long as their are not transfers scheduled on the bus.
Enter crappy older hardware. there are older usb HCs which cannot power up a root hub port once it is powered down without powering down the entire hub.
Enter selective suspend.
it does 2 things. one, it lets you tell the bus when you are ready to power off. two, it lets the bus coordinate when devices are going to be powered off, esp the generic parent (usbccgp) case where power states on the function stacks are virtual. by leveraging #2, the usb core can compensate for the crappy older hardware AND let drivers of different functions who share the same physical hw port coordinate their power states.
So yes, at the very least all functions of a device must notify the bus of selective suspend to be turned off. In the single funciton case (usbhub is your parent), this is instaneous on vista and later. IN the multifunciton case, all functions must opt in (the underlying reason is that if any function needs to wake from Dx (say a mouse) and the other functions are not yet ready to go into Dx, the device itself will stay in D0 and USB does not allow a device to trigger remote wake (e.g. wake) from the D0 state). On crappy older hw, all of the devices on the bus must opt into selective suspend to turn things off
So, in conclusion
d
> it does 2 things. one, it lets you tell the bus when you are ready to power off. two, it lets the bus
coordinate when devices are going to be powered off, esp the generic parent (usbccgp) case where
power states on the function stacks are virtual. by leveraging #2, the usb core can compensate for the
crappy older hardware AND let drivers of different functions who share the same physical hw port
coordinate their power states.
Thanks Doron, this is the best explanation of the purpose of the selective suspend.
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks Doron and Pavel A Had to read more than once, but now i know why
processor states are needed in relation to selective suspend.
rtshiva
On Tue, Jul 14, 2009 at 10:10 PM, wrote:
> let’s clarify a couple of things
>
> the amount of current drawn from a usb device on the usb wire is tiny
> compared to the amount of power you can save if you can put the processor
> into a low C state. Bus master traffic keeps the processor in C0 to
> maintain cache coherency (e.g. it must snoop), running the usb schedule
> causes bus master traffic. note that the schedule itself must be off, but
> the devices can remain on as long as their are not transfers scheduled on
> the bus.
>
> Enter crappy older hardware. there are older usb HCs which cannot power up
> a root hub port once it is powered down without powering down the entire
> hub.
>
> Enter selective suspend.
>
> it does 2 things. one, it lets you tell the bus when you are ready to
> power off. two, it lets the bus coordinate when devices are going to be
> powered off, esp the generic parent (usbccgp) case where power states on the
> function stacks are virtual. by leveraging #2, the usb core can compensate
> for the crappy older hardware AND let drivers of different functions who
> share the same physical hw port coordinate their power states.
>
> So yes, at the very least all functions of a device must notify the bus of
> selective suspend to be turned off. In the single funciton case (usbhub is
> your parent), this is instaneous on vista and later. IN the multifunciton
> case, all functions must opt in (the underlying reason is that if any
> function needs to wake from Dx (say a mouse) and the other functions are not
> yet ready to go into Dx, the device itself will stay in D0 and USB does not
> allow a device to trigger remote wake (e.g. wake) from the D0 state). On
> crappy older hw, all of the devices on the bus must opt into selective
> suspend to turn things off
>
> So, in conclusion
> 1) it is not a bug that all devices are required to opt into sel suspend
> under some scenarios (pre Vista, busted HCs)
> 2) the OP is correct to look at processor C state b/c that is where the
> real power savings are
>
> d
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>