Fast sleep or wait

NTDEV
1

I am working with a driver where I due to the hardware construction need to wait for 1 ms between accessing the hardware. I am using the KeDelayExecution command to wait for 1 ms. My problem is that KeDelayExecution always waits for at least 1 timeslice, so my delay is always between 10-15ms which is much to long. I have tried with the KeStallExecution command. It works but as it makes a busywait it takes to much cpu power.

Is it possible to wait for 1 ms in the driver in any way without using cpu power?

Regards
Bent

2

What you can do is change the clock resolution with ExSetTimerResolution and
then schedule a one shot timer which fires a DPC after 1 ms. Not that this
is a great solution, the clock resolution is a resource that many components
are competing for. The right answer is probably to change the hardware to
remove the requirement or have it notify the OS when it’s ready.

//Daniel

wrote in message news:xxxxx@ntdev…
>I am working with a driver where I due to the hardware construction need to
>wait for 1 ms between accessing the hardware. I am using the
>KeDelayExecution command to wait for 1 ms. My problem is that
>KeDelayExecution always waits for at least 1 timeslice, so my delay is
>always between 10-15ms which is much to long. I have tried with the
>KeStallExecution command. It works but as it makes a busywait it takes to
>much cpu power.
>
> Is it possible to wait for 1 ms in the driver in any way without using cpu
> power?
>
> Regards
> Bent
>

3

Yep. This is a known problem; the usual solution is to redesign the
hardware so it doesn’t require a wait. For example, if the hardware
generates an interrupt after 1ms this is good. But I’ve had this argument
before with hardware designers, who say silly things like “Well, all you
need to do is just reprogram the timer chip and hijack the timer interrupt
vector”, which is what a hardware designer who works on an MS-DOS machine or
who works on a bare machine will propose (and hey, it can save $0.15/board!)
Such designs will not work in any operating system I’ve known of (a few
still have 55ms timers!). Hardware designers often say “the software will
solve the problem” and don’t know what “the” software is!

As far as I know, there is no way to do a 1ms delay without doing a
busy-wait, which, as you discovered, hogs the CPU and severely damages
responsiveness.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@napatech.com
Sent: Tuesday, July 05, 2011 7:00 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Fast sleep or wait

I am working with a driver where I due to the hardware construction need to
wait for 1 ms between accessing the hardware. I am using the
KeDelayExecution command to wait for 1 ms. My problem is that
KeDelayExecution always waits for at least 1 timeslice, so my delay is
always between 10-15ms which is much to long. I have tried with the
KeStallExecution command. It works but as it makes a busywait it takes to
much cpu power.

Is it possible to wait for 1 ms in the driver in any way without using cpu
power?

Regards
Bent

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.

4

Changing the clock interval using its documented interface is not as bad as
hijacking the clock interrupt. The minimum clock interval on the OS has a
hard coded limit which seems to have been reduced from 1000us to 500us in
Windows 7.

Setting that to the minimum, in combination with a kernel timer allows you
to do a wait of 1ms (plus the extra latency of other DPCs and ISRs running
on the same CPU).

The hardware timers are programmable in high resolution, the 8254 has a
resolution of 1 us, the HPET has a resolution which is expressed in
PETAseconds, can you believe it. A pity that there seems to be no interface
to access hardware based aperiodic timers, there would be many other good
purposes for these than just supporting incompatible hardware.

//Daniel

“Joseph M. Newcomer” wrote in message
news:xxxxx@ntdev…
> Yep. This is a known problem; the usual solution is to redesign the
> hardware so it doesn’t require a wait. For example, if the hardware
> generates an interrupt after 1ms this is good. But I’ve had this argument
> before with hardware designers, who say silly things like “Well, all you
> need to do is just reprogram the timer chip and hijack the timer interrupt
> vector”, which is what a hardware designer who works on an MS-DOS machine
> or
> who works on a bare machine will propose (and hey, it can save
> $0.15/board!)
> Such designs will not work in any operating system I’ve known of (a few
> still have 55ms timers!). Hardware designers often say “the software will
> solve the problem” and don’t know what “the” software is!
>
> As far as I know, there is no way to do a 1ms delay without doing a
> busy-wait, which, as you discovered, hogs the CPU and severely damages
> responsiveness.
> joe
>
> -----Original Message-----

5

Just open Media Center - it goes to fast timer mode for you :slight_smile:

Mark Roddy

On Fri, Jul 8, 2011 at 8:02 AM, wrote:
> Changing the clock interval using its documented interface is not as bad as
> hijacking the clock interrupt. The minimum clock interval on the OS has a
> hard coded limit which seems to have been reduced from 1000us to 500us in
> Windows 7.
>
> Setting that to the minimum, in combination with a kernel timer allows you
> to do a wait of 1ms (plus the extra latency of other DPCs and ISRs running
> on the same CPU).
>
> The hardware timers are programmable in high resolution, the 8254 has a
> resolution of 1 us, the HPET has a resolution which is expressed in
> PETAseconds, can you believe it. A pity that there seems to be no interface
> to access hardware based aperiodic timers, there would be many other good
> purposes for these than just supporting incompatible hardware.
>
> //Daniel
>
>
>
> “Joseph M. Newcomer” wrote in message
> news:xxxxx@ntdev…
>> Yep. ?This is a known problem; the usual solution is to redesign the
>> hardware so it doesn’t require a wait. ?For example, if the hardware
>> generates an interrupt after 1ms this is good. ?But I’ve had this argument
>> before with hardware designers, who say silly things like “Well, all you
>> need to do is just reprogram the timer chip and hijack the timer interrupt
>> vector”, which is what a hardware designer who works on an MS-DOS machine
>> or
>> who works on a bare machine will propose (and hey, it can save
>> $0.15/board!)
>> Such designs will not work in any operating system I’ve known of (a few
>> still have 55ms timers!). ?Hardware designers often say “the software will
>> solve the problem” and don’t know what “the” software is!
>>
>> As far as I know, there is no way to do a 1ms delay without doing a
>> busy-wait, which, as you discovered, hogs the CPU and severely damages
>> responsiveness.
>> joe
>>
>> -----Original Message-----
>
>
>
> —
> 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
>

6

OK, so we should all now be prepared to answer the question, “how can I
launch Media Center from a driver?” :slight_smile:

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Mark Roddy” wrote in message news:xxxxx@ntdev…

Just open Media Center - it goes to fast timer mode for you :slight_smile:

Mark Roddy

On Fri, Jul 8, 2011 at 8:02 AM, wrote:
> Changing the clock interval using its documented interface is not as bad
> as
> hijacking the clock interrupt. The minimum clock interval on the OS has a
> hard coded limit which seems to have been reduced from 1000us to 500us in
> Windows 7.
>
> Setting that to the minimum, in combination with a kernel timer allows you
> to do a wait of 1ms (plus the extra latency of other DPCs and ISRs running
> on the same CPU).
>
> The hardware timers are programmable in high resolution, the 8254 has a
> resolution of 1 us, the HPET has a resolution which is expressed in
> PETAseconds, can you believe it. A pity that there seems to be no
> interface
> to access hardware based aperiodic timers, there would be many other good
> purposes for these than just supporting incompatible hardware.
>
> //Daniel
>
>
>
> “Joseph M. Newcomer” wrote in message
> news:xxxxx@ntdev…
>> Yep. This is a known problem; the usual solution is to redesign the
>> hardware so it doesn’t require a wait. For example, if the hardware
>> generates an interrupt after 1ms this is good. But I’ve had this
>> argument
>> before with hardware designers, who say silly things like “Well, all you
>> need to do is just reprogram the timer chip and hijack the timer
>> interrupt
>> vector”, which is what a hardware designer who works on an MS-DOS machine
>> or
>> who works on a bare machine will propose (and hey, it can save
>> $0.15/board!)
>> Such designs will not work in any operating system I’ve known of (a few
>> still have 55ms timers!). Hardware designers often say “the software
>> will
>> solve the problem” and don’t know what “the” software is!
>>
>> As far as I know, there is no way to do a 1ms delay without doing a
>> busy-wait, which, as you discovered, hogs the CPU and severely damages
>> responsiveness.
>> joe
>>
>> -----Original Message-----
>
>
>
> —
> 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
>

7

Sorry that should be femtoseconds (10^-15) and not petaseconds. Still the
minimum resolution appears to be 100 nanoseconds as the minimum recommended
clock frequency is 10Mhz.

//Daniel

wrote in message news:xxxxx@ntdev…
> The hardware timers are programmable in high resolution, the 8254 has a
> resolution of 1 us, the HPET has a resolution which is expressed in
> PETAseconds, can you believe it. A pity that there seems to be no
> interface to access hardware based aperiodic timers, there would be many
> other good purposes for these than just supporting incompatible hardware.
>
> //Daniel
>
>
>
> “Joseph M. Newcomer” wrote in message
> news:xxxxx@ntdev…
>> Yep. This is a known problem; the usual solution is to redesign the
>> hardware so it doesn’t require a wait. For example, if the hardware
>> generates an interrupt after 1ms this is good. But I’ve had this
>> argument
>> before with hardware designers, who say silly things like “Well, all you
>> need to do is just reprogram the timer chip and hijack the timer
>> interrupt
>> vector”, which is what a hardware designer who works on an MS-DOS machine
>> or
>> who works on a bare machine will propose (and hey, it can save
>> $0.15/board!)
>> Such designs will not work in any operating system I’ve known of (a few
>> still have 55ms timers!). Hardware designers often say “the software
>> will
>> solve the problem” and don’t know what “the” software is!
>>
>> As far as I know, there is no way to do a 1ms delay without doing a
>> busy-wait, which, as you discovered, hogs the CPU and severely damages
>> responsiveness.
>> joe
>>
>> -----Original Message-----
>
>
>

8

That’s interesting. Previously, Microsoft would tell us (at WinHEC, for
example) “We’re thinking of giving you finer time control in the next
release of Windows”, and that has been the line since we first requested
this capability in Windows NT 4.0. I had not seen it happen. However, I
had not done anything yet with Windows 7.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Friday, July 08, 2011 8:02 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Fast sleep or wait

Changing the clock interval using its documented interface is not as bad as
hijacking the clock interrupt. The minimum clock interval on the OS has a
hard coded limit which seems to have been reduced from 1000us to 500us in
Windows 7.

Setting that to the minimum, in combination with a kernel timer allows you
to do a wait of 1ms (plus the extra latency of other DPCs and ISRs running
on the same CPU).

The hardware timers are programmable in high resolution, the 8254 has a
resolution of 1 us, the HPET has a resolution which is expressed in
PETAseconds, can you believe it. A pity that there seems to be no interface
to access hardware based aperiodic timers, there would be many other good
purposes for these than just supporting incompatible hardware.

//Daniel

“Joseph M. Newcomer” wrote in message
news:xxxxx@ntdev…
> Yep. This is a known problem; the usual solution is to redesign the
> hardware so it doesn’t require a wait. For example, if the hardware
> generates an interrupt after 1ms this is good. But I’ve had this argument
> before with hardware designers, who say silly things like “Well, all you
> need to do is just reprogram the timer chip and hijack the timer interrupt
> vector”, which is what a hardware designer who works on an MS-DOS machine
> or
> who works on a bare machine will propose (and hey, it can save
> $0.15/board!)
> Such designs will not work in any operating system I’ve known of (a few
> still have 55ms timers!). Hardware designers often say “the software will
> solve the problem” and don’t know what “the” software is!
>
> As far as I know, there is no way to do a 1ms delay without doing a
> busy-wait, which, as you discovered, hogs the CPU and severely damages
> responsiveness.
> joe
>
> -----Original Message-----

—
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

9

As an experiment it’s interesting also to see what happens if you hack your
way around these hard limits and push the clock interval back further to 1
us.

It obviously hurts perrformance but what you get is a system that is very
responsive and very pleasant to work with for the lighter tasks.

Things that take little time run faster. But tasks that take longer now take
a lot longer.



ClockRes v2.0 - View the system clock resolution
Copyright (C) 2009 Mark Russinovich
SysInternals - www.sysinternals.com

Maximum timer interval: 15.600 ms
Minimum timer interval: 0.001 ms
Current timer interval: 0.001 ms

Much cooler than opening Media Center for sure.

//Daniel

“Joseph M. Newcomer” wrote in message
news:xxxxx@ntdev…
> That’s interesting. Previously, Microsoft would tell us (at WinHEC, for
> example) “We’re thinking of giving you finer time control in the next
> release of Windows”, and that has been the line since we first requested
> this capability in Windows NT 4.0. I had not seen it happen. However, I
> had not done anything yet with Windows 7.
> joe
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@resplendence.com
> Sent: Friday, July 08, 2011 8:02 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Fast sleep or wait
>
> Changing the clock interval using its documented interface is not as bad
> as
> hijacking the clock interrupt. The minimum clock interval on the OS has a
> hard coded limit which seems to have been reduced from 1000us to 500us in
> Windows 7.
>
> Setting that to the minimum, in combination with a kernel timer allows you
> to do a wait of 1ms (plus the extra latency of other DPCs and ISRs running
> on the same CPU).
>
> The hardware timers are programmable in high resolution, the 8254 has a
> resolution of 1 us, the HPET has a resolution which is expressed in
> PETAseconds, can you believe it. A pity that there seems to be no
> interface
> to access hardware based aperiodic timers, there would be many other good
> purposes for these than just supporting incompatible hardware.
>
> //Daniel
>
>
>
> “Joseph M. Newcomer” wrote in message
> news:xxxxx@ntdev…
>> Yep. This is a known problem; the usual solution is to redesign the
>> hardware so it doesn’t require a wait. For example, if the hardware
>> generates an interrupt after 1ms this is good. But I’ve had this
>> argument
>> before with hardware designers, who say silly things like “Well, all you
>> need to do is just reprogram the timer chip and hijack the timer
>> interrupt
>> vector”, which is what a hardware designer who works on an MS-DOS machine
>> or
>> who works on a bare machine will propose (and hey, it can save
>> $0.15/board!)
>> Such designs will not work in any operating system I’ve known of (a few
>> still have 55ms timers!). Hardware designers often say “the software
>> will
>> solve the problem” and don’t know what “the” software is!
>>
>> As far as I know, there is no way to do a 1ms delay without doing a
>> busy-wait, which, as you discovered, hogs the CPU and severely damages
>> responsiveness.
>> joe
>>
>> -----Original Message-----
>
>
>
> —
> 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
>
>

10

Followed quickly by “How do I launch Media Center from the MBR?”

Gary G. Little
C 952-454-4629
H 952-223-1349

“Yes, Virginia there really is such a thing as a stupid question.”

On Jul 8, 2011, at 9:27, “Scott Noone” wrote:

> OK, so we should all now be prepared to answer the question, “how can I launch Media Center from a driver?” :slight_smile:
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> Just open Media Center - it goes to fast timer mode for you :slight_smile:
>
> Mark Roddy
>
>
>
> On Fri, Jul 8, 2011 at 8:02 AM, wrote:
>> Changing the clock interval using its documented interface is not as bad as
>> hijacking the clock interrupt. The minimum clock interval on the OS has a
>> hard coded limit which seems to have been reduced from 1000us to 500us in
>> Windows 7.
>>
>> Setting that to the minimum, in combination with a kernel timer allows you
>> to do a wait of 1ms (plus the extra latency of other DPCs and ISRs running
>> on the same CPU).
>>
>> The hardware timers are programmable in high resolution, the 8254 has a
>> resolution of 1 us, the HPET has a resolution which is expressed in
>> PETAseconds, can you believe it. A pity that there seems to be no interface
>> to access hardware based aperiodic timers, there would be many other good
>> purposes for these than just supporting incompatible hardware.
>>
>> //Daniel
>>
>>
>>
>> “Joseph M. Newcomer” wrote in message
>> news:xxxxx@ntdev…
>>> Yep. This is a known problem; the usual solution is to redesign the
>>> hardware so it doesn’t require a wait. For example, if the hardware
>>> generates an interrupt after 1ms this is good. But I’ve had this argument
>>> before with hardware designers, who say silly things like “Well, all you
>>> need to do is just reprogram the timer chip and hijack the timer interrupt
>>> vector”, which is what a hardware designer who works on an MS-DOS machine
>>> or
>>> who works on a bare machine will propose (and hey, it can save
>>> $0.15/board!)
>>> Such designs will not work in any operating system I’ve known of (a few
>>> still have 55ms timers!). Hardware designers often say “the software will
>>> solve the problem” and don’t know what “the” software is!
>>>
>>> As far as I know, there is no way to do a 1ms delay without doing a
>>> busy-wait, which, as you discovered, hogs the CPU and severely damages
>>> responsiveness.
>>> joe
>>>
>>> -----Original Message-----
>>
>>
>>
>> —
>> 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
>
>
> —
> 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

11

Does it really require launching Media Center, or just launching any program
that does a timeSetEvent that forces the timer to go into its
higher-resolution mode? Sounds like launching Media Center is just one way
to cause this to happen. It might be simpler just to start a service that
does the timeSetEvent, and until that service is running (and it can open
the driver and send down a DeviceIoControl to say “I’ve started a
high-resolution timer”) then the driver cannot depend on having accurate
timings.

joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Sunday, July 10, 2011 11:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Fast sleep or wait

Followed quickly by “How do I launch Media Center from the MBR?”

Gary G. Little
C 952-454-4629
H 952-223-1349

“Yes, Virginia there really is such a thing as a stupid question.”

On Jul 8, 2011, at 9:27, “Scott Noone” wrote:

> OK, so we should all now be prepared to answer the question, “how can I
launch Media Center from a driver?” :slight_smile:
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> Just open Media Center - it goes to fast timer mode for you :slight_smile:
>
> Mark Roddy
>
>
>
> On Fri, Jul 8, 2011 at 8:02 AM, wrote:
>> Changing the clock interval using its documented interface is not as bad
as
>> hijacking the clock interrupt. The minimum clock interval on the OS has a
>> hard coded limit which seems to have been reduced from 1000us to 500us in
>> Windows 7.
>>
>> Setting that to the minimum, in combination with a kernel timer allows
you
>> to do a wait of 1ms (plus the extra latency of other DPCs and ISRs
running
>> on the same CPU).
>>
>> The hardware timers are programmable in high resolution, the 8254 has a
>> resolution of 1 us, the HPET has a resolution which is expressed in
>> PETAseconds, can you believe it. A pity that there seems to be no
interface
>> to access hardware based aperiodic timers, there would be many other good
>> purposes for these than just supporting incompatible hardware.
>>
>> //Daniel
>>
>>
>>
>> “Joseph M. Newcomer” wrote in message
>> news:xxxxx@ntdev…
>>> Yep. This is a known problem; the usual solution is to redesign the
>>> hardware so it doesn’t require a wait. For example, if the hardware
>>> generates an interrupt after 1ms this is good. But I’ve had this
argument
>>> before with hardware designers, who say silly things like “Well, all you
>>> need to do is just reprogram the timer chip and hijack the timer
interrupt
>>> vector”, which is what a hardware designer who works on an MS-DOS
machine
>>> or
>>> who works on a bare machine will propose (and hey, it can save
>>> $0.15/board!)
>>> Such designs will not work in any operating system I’ve known of (a few
>>> still have 55ms timers!). Hardware designers often say “the software
will
>>> solve the problem” and don’t know what “the” software is!
>>>
>>> As far as I know, there is no way to do a 1ms delay without doing a
>>> busy-wait, which, as you discovered, hogs the CPU and severely damages
>>> responsiveness.
>>> joe
>>>
>>> -----Original Message-----
>>
>>
>>
>> —
>> 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
>
>
> —
> 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

—
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

12

“it was a joke, son” - foghorn leghorn

My very small point was that the aura of “don’t change the timer it is
dangerous”, which used to be the prevailing wisdom regarding timer
manipulation, has been nullified by the fact that standard user apps
do just that.

Mark Roddy

On Mon, Jul 11, 2011 at 3:26 PM, Joseph M. Newcomer
wrote:
> Does it really require launching Media Center, or just launching any program
> that does a timeSetEvent that forces the timer to go into its
> higher-resolution mode? ?Sounds like launching Media Center is just one way
> to cause this to happen. ?It might be simpler just to start a service that
> does the timeSetEvent, and until that service is running (and it can open
> the driver and send down a DeviceIoControl to say “I’ve started a
> high-resolution timer”) then the driver cannot depend on having accurate
> timings.
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?joe
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> Sent: Sunday, July 10, 2011 11:54 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Fast sleep or wait
>
> Followed quickly by “How do I launch Media Center from the MBR?”
>
> Gary G. Little
> C 952-454-4629
> H 952-223-1349
>
> “Yes, Virginia there really is such a thing as a stupid question.”
>
> On Jul 8, 2011, at 9:27, “Scott Noone” wrote:
>
>> OK, so we should all now be prepared to answer the question, “how can I
> launch Media Center from a driver?” :slight_smile:
>>
>> -scott
>>
>> –
>> Scott Noone
>> Consulting Associate and Chief System Problem Analyst
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>> “Mark Roddy” ?wrote in message news:xxxxx@ntdev…
>>
>> Just open Media Center - it goes to fast timer mode for you :slight_smile:
>>
>> Mark Roddy
>>
>>
>>
>> On Fri, Jul 8, 2011 at 8:02 AM, ? wrote:
>>> Changing the clock interval using its documented interface is not as bad
> as
>>> hijacking the clock interrupt. The minimum clock interval on the OS has a
>>> hard coded limit which seems to have been reduced from 1000us to 500us in
>>> Windows 7.
>>>
>>> Setting that to the minimum, in combination with a kernel timer allows
> you
>>> to do a wait of 1ms (plus the extra latency of other DPCs and ISRs
> running
>>> on the same CPU).
>>>
>>> The hardware timers are programmable in high resolution, the 8254 has a
>>> resolution of 1 us, the HPET has a resolution which is expressed in
>>> PETAseconds, can you believe it. A pity that there seems to be no
> interface
>>> to access hardware based aperiodic timers, there would be many other good
>>> purposes for these than just supporting incompatible hardware.
>>>
>>> //Daniel
>>>
>>>
>>>
>>> “Joseph M. Newcomer” wrote in message
>>> news:xxxxx@ntdev…
>>>> Yep. ?This is a known problem; the usual solution is to redesign the
>>>> hardware so it doesn’t require a wait. ?For example, if the hardware
>>>> generates an interrupt after 1ms this is good. ?But I’ve had this
> argument
>>>> before with hardware designers, who say silly things like “Well, all you
>>>> need to do is just reprogram the timer chip and hijack the timer
> interrupt
>>>> vector”, which is what a hardware designer who works on an MS-DOS
> machine
>>>> or
>>>> who works on a bare machine will propose (and hey, it can save
>>>> $0.15/board!)
>>>> Such designs will not work in any operating system I’ve known of (a few
>>>> still have 55ms timers!). ?Hardware designers often say “the software
> will
>>>> solve the problem” and don’t know what “the” software is!
>>>>
>>>> As far as I know, there is no way to do a 1ms delay without doing a
>>>> busy-wait, which, as you discovered, hogs the CPU and severely damages
>>>> responsiveness.
>>>> joe
>>>>
>>>> -----Original Message-----
>>>
>>>
>>>
>>> —
>>> 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
>>
>>
>> —
>> 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
>
> —
> 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
>
>
> —
> 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
>

13

Here is an example how to call NtSetTimerResolution:

http://social.msdn.microsoft.com/Forums/en-GB/netfxtoolsdev/thread/8aea13d9-35f1-4b66-a5b4-726651d985f7

Interestingly, timeSetEvent in MSDN is marked as obsolete and CreateTimerQueueTimer is named as the replacement - but the latter does not seem to specify the resolution, as timeSetEvent does.

Also, NtSetTimerResolution is still not documented in MSDN, but the kernel side API, ExSetTimerResolution, is.

Regards,
–pa

14

Mark Roddy wrote:

“it was a joke, son” - foghorn leghorn

My very small point was that the aura of “don’t change the timer it is
dangerous”, which used to be the prevailing wisdom regarding timer
manipulation, has been nullified by the fact that standard user apps
do just that.

Yes. It’s actually the timeBeginPeriod API that does this. That’s a
standard mmsystem.h API, and any user-mode app can call it.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.