KMDF, USB selective suspend and Idle timeout

NTDEV
1

Hello all,
Basically my questions are continuation of discussion in the following thread:
http://www.osronline.com/showThread.cfm?link=166414

I have been told that our competitors products support an SS idle timeout of 500 ms and hence we have to support to meet the power consumption benchmarks for our product. I see in previous discussion thread that 1 sec is considered too short…so is 500 ms not achievable on any Windows system ?
Can some one from Microsoft USB core team at least comment on what is the minimum value that they have achieved on an ideal working device on lets say Windows 7? I think this number would be helpful for all the new folks stepping into USB SS for the first time.

As mentioned in earlier post I have come to same conclusion with our product, if the resume immediately follows the suspend (100 - 150 ms after) then the USB core fails to do a resume or the previous suspend continues till the next resume but our SS KMDF driver does get a D0Entry as if the device was resumed. I am using power managed queues in our KMDF SS driver. If Idle timeout value is increased (5 sec or 10 sec) this behavior is still there but seen less frequently due to large timeout value. So I dont think this issue is tied to a short timeout value used.

Doron mentioned the following regaring the above problem:
“it is defiitely not something that wdf should be handling. either it is an issue in the usb core or in your hw. i would start with your hw”

I am not sure if the problem is with our hw…I tried to investigate that part and I kind of agree with the HW folks that the resume/suspend is completely driven by the master (the host) and the device merely reacts to it by being ready and servicing any incoming request after the resume. So I am at this point suspecting its an USB core issue. I did take a Windows 7 USB etl trace but dont know how to to interpret it at this time (I can send that out if needed ).

Now I wanted to know what my options for workaround are for the above behaviour in our KMDF SS driver. I didnt see any setting in KMDF that would allow the power managed queue to be configured to delay the delivery of requests by certain time …thus causing the wakeup of the device to be delayed by sometime when its recently suspended. Let me know if I am missing something here:

  1. Can I use non-power managed queue and self-managed IO to do the above and control the timing when our device is resumed or suspended? Will that work?
  2. Can I use IRP preprocessing with KMDF power managed queues and kind of delay the request delivery back to WDF by the time needed for a good resume after suspend?

Thanks for your patience and I apologize for this long post as I wanted to include all the info/questions.

Any comments or advise that would help me understand the problem or better resolve it are most welcome. Thanks for that.

Adam (OP of the earlier post)… please let me know if you were able to solve your problem earlier …that would help too.

Thanks again,
Nate D.

2

> I see in previous discussion thread that 1 sec is considered too short…so is 500 ms not achievable on any Windows system ?

I would think that a 500 ms idle timeout is achievable, just not desirable. There is a cost with powering your device up and down, and if you do this too often your power consumption will spike with the constant power up/down cycles and you would be better off just staying in your operational power state. It is all about finding the right settings that tailor to your device’s usage scenarios to get maximal power savings. Shorter timeout period is not always better.

As for the Suspend/Resume issue - hopefully someone more knowledgeable about the USB stack will chime in.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@coolgoose.com
Sent: Wednesday, March 17, 2010 7:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF, USB selective suspend and Idle timeout

Hello all,
Basically my questions are continuation of discussion in the following thread:
http://www.osronline.com/showThread.cfm?link=166414

I have been told that our competitors products support an SS idle timeout of 500 ms and hence we have to support to meet the power consumption benchmarks for our product. I see in previous discussion thread that 1 sec is considered too short…so is 500 ms not achievable on any Windows system ?
Can some one from Microsoft USB core team at least comment on what is the minimum value that they have achieved on an ideal working device on lets say Windows 7? I think this number would be helpful for all the new folks stepping into USB SS for the first time.

As mentioned in earlier post I have come to same conclusion with our product, if the resume immediately follows the suspend (100 - 150 ms after) then the USB core fails to do a resume or the previous suspend continues till the next resume but our SS KMDF driver does get a D0Entry as if the device was resumed. I am using power managed queues in our KMDF SS driver. If Idle timeout value is increased (5 sec or 10 sec) this behavior is still there but seen less frequently due to large timeout value. So I dont think this issue is tied to a short timeout value used.

Doron mentioned the following regaring the above problem:
“it is defiitely not something that wdf should be handling. either it is an issue in the usb core or in your hw. i would start with your hw”

I am not sure if the problem is with our hw…I tried to investigate that part and I kind of agree with the HW folks that the resume/suspend is completely driven by the master (the host) and the device merely reacts to it by being ready and servicing any incoming request after the resume. So I am at this point suspecting its an USB core issue. I did take a Windows 7 USB etl trace but dont know how to to interpret it at this time (I can send that out if needed ).

Now I wanted to know what my options for workaround are for the above behaviour in our KMDF SS driver. I didnt see any setting in KMDF that would allow the power managed queue to be configured to delay the delivery of requests by certain time …thus causing the wakeup of the device to be delayed by sometime when its recently suspended. Let me know if I am missing something here:

  1. Can I use non-power managed queue and self-managed IO to do the above and control the timing when our device is resumed or suspended? Will that work?
  2. Can I use IRP preprocessing with KMDF power managed queues and kind of delay the request delivery back to WDF by the time needed for a good resume after suspend?

Thanks for your patience and I apologize for this long post as I wanted to include all the info/questions.

Any comments or advise that would help me understand the problem or better resolve it are most welcome. Thanks for that.

Adam (OP of the earlier post)… please let me know if you were able to solve your problem earlier …that would help too.

Thanks again,
Nate 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

3

I’d be interested to see the ETW log, you can e-mail it to me.

Brandon Wilson wrote:

> I see in previous discussion thread that 1 sec is considered too short…so is 500 ms not achievable on any Windows system ?

I would think that a 500 ms idle timeout is achievable, just not desirable. There is a cost with powering your device up and down, and if you do this too often your power consumption will spike with the constant power up/down cycles and you would be better off just staying in your operational power state. It is all about finding the right settings that tailor to your device’s usage scenarios to get maximal power savings. Shorter timeout period is not always better.

As for the Suspend/Resume issue - hopefully someone more knowledgeable about the USB stack will chime in.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@coolgoose.com
Sent: Wednesday, March 17, 2010 7:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF, USB selective suspend and Idle timeout

Hello all,
Basically my questions are continuation of discussion in the following thread:
http://www.osronline.com/showThread.cfm?link=166414

I have been told that our competitors products support an SS idle timeout of 500 ms and hence we have to support to meet the power consumption benchmarks for our product. I see in previous discussion thread that 1 sec is considered too short…so is 500 ms not achievable on any Windows system ?
Can some one from Microsoft USB core team at least comment on what is the minimum value that they have achieved on an ideal working device on lets say Windows 7? I think this number would be helpful for all the new folks stepping into USB SS for the first time.

As mentioned in earlier post I have come to same conclusion with our product, if the resume immediately follows the suspend (100 - 150 ms after) then the USB core fails to do a resume or the previous suspend continues till the next resume but our SS KMDF driver does get a D0Entry as if the device was resumed. I am using power managed queues in our KMDF SS driver. If Idle timeout value is increased (5 sec or 10 sec) this behavior is still there but seen less frequently due to large timeout value. So I dont think this issue is tied to a short timeout value used.

Doron mentioned the following regaring the above problem:
“it is defiitely not something that wdf should be handling. either it is an issue in the usb core or in your hw. i would start with your hw”

I am not sure if the problem is with our hw…I tried to investigate that part and I kind of agree with the HW folks that the resume/suspend is completely driven by the master (the host) and the device merely reacts to it by being ready and servicing any incoming request after the resume. So I am at this point suspecting its an USB core issue. I did take a Windows 7 USB etl trace but dont know how to to interpret it at this time (I can send that out if needed ).

Now I wanted to know what my options for workaround are for the above behaviour in our KMDF SS driver. I didnt see any setting in KMDF that would allow the power managed queue to be configured to delay the delivery of requests by certain time …thus causing the wakeup of the device to be delayed by sometime when its recently suspended. Let me know if I am missing something here:

  1. Can I use non-power managed queue and self-managed IO to do the above and control the timing when our device is resumed or suspended? Will that work?
  2. Can I use IRP preprocessing with KMDF power managed queues and kind of delay the request delivery back to WDF by the time needed for a good resume after suspend?

Thanks for your patience and I apologize for this long post as I wanted to include all the info/questions.

Any comments or advise that would help me understand the problem or better resolve it are most welcome. Thanks for that.

Adam (OP of the earlier post)… please let me know if you were able to solve your problem earlier …that would help too.

Thanks again,
Nate 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

4

Thanks Philip. I have sent the ETW logs to you.

Nate

5

Looks like the same root cause as this thread:
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/caa5ba55095000bf/23a34ca8c15b2a2f

The hotfix is available now so go ahead and try it:
http://support.microsoft.com/kb/978258

Let us know how it goes.

xxxxx@coolgoose.com wrote:

Thanks Philip. I have sent the ETW logs to you.

Nate

6

Thank you very much Philip. The issue occurs on multiple machines (different type/make etc). So far I have tested the hotfix on one machine and its looking really good. I think this hotfix should resolve the issue. I will test this further tomorrow on some other machines and confirm that.

I really appreciate your quick response to this.

Thanks Brandon for your insight…I completely agree that shorter timeout is not always better. We will be evaluating the right trade-off value but so far we were unable to test reliably.