OSR's ntdev List: Changing Timer Resolution from within Kernel drivers

Message 1 of 9

21 Mar 02 06:31

Christiaan Ghijselinck

xxxxxx@Skynet.be

Join Date: 21 Mar 2002

Posts To This List: 436

Changing Timer Resolution from within Kernel drivers

I'm currently developing a dedicated kernel driver for an I2C interface card for which I need to set timers with milli-seconds accuracy. I know about the existence of the "timeBeginPeriod" and its undocumented native API counterpart "NtSetTimerResolution" to change the default 10 mS granularity. However, both procedures cannot be used from within kernel drivers ( or ? ). Does anyone know about a way to increase the timer resolution from within a kernel driver temporarely, that would allow me to use the "KeSetTimer" up to a milli-second accuracy ?

Message 2 of 9

21 Mar 02 09:03

ntdev member 2362

xxxxxx@midcore.com

Join Date:

Posts To This List: 75

Re: Changing Timer Resolution from within Kernel drivers

Here's a snippet taken from a previous reply to another post (the subject was "atapi.sys hangs CPU for many seconds") which bay be of intrest: "I think that KeStallExecutionProcessor runs with interrupts disabled, so the IRQL would be 31. Just disassemble the function; it's pretty small. I looked at it years ago to figure out how it did the high-resolution timing. It's kinda clever; it measures how many of a given loop iteration it can execute in 1/18th of a second or whatever at bootup time, and then scales that down to the appropriate number of loops in the specified number of microseconds. (Thus, there's no timer actually involved when you call it.)" You might be able to use the same kind of logic in your driver to obtain higher resolution timing, depending on you exact needs. Regards, Ed Lau MidCore Software, Inc. 900 Straits Tpke Middlebury, CT 06762 www.midcore.com ----- Original Message ----- From: Ghijselinck To: NT Developers Interest List Sent: Thursday, March 21, 2002 6:30 AM Subject: [ntdev] Changing Timer Resolution from within Kernel drivers I'm currently developing a dedicated kernel driver for an I2C interface card for which I need to set timers with milli-seconds accuracy. I know about the existence of the "timeBeginPeriod" and its undocumented native API counterpart "NtSetTimerResolution" to change the default 10 mS granularity. However, both procedures cannot be used from within kernel drivers ( or ? ). Does anyone know about a way to increase the timer resolution from within a kernel driver temporarely, that would allow me to use the "KeSetTimer" up to a milli-second accuracy ? --- You are currently subscribed to ntdev as: xxxxx@midcore.com To unsubscribe send a blank email to %%email.unsub%% --

Message 3 of 9

21 Mar 02 09:04

Stephan Wolf

xxxxxx@hotmail.com (Stephan Wolf)

Join Date: 11 Jan 2002

Posts To This List: 114

Re: Changing Timer Resolution from within Kernel drivers

Try ExSetTimerResolution(). Stephan --- On Thu, 21 Mar 2002 06:30:19 -0500, "Ghijselinck" <xxxxx@Skynet.be> wrote: >I'm currently developing a dedicated kernel driver for an I2C interface >card for which I need to set timers with milli-seconds accuracy. I know >about the existence of the "timeBeginPeriod" and its undocumented native >API counterpart "NtSetTimerResolution" to change the default 10 mS >granularity. However, both procedures cannot be used from within kernel >drivers ( or ? ). Does anyone know about a way to increase the timer >resolution from within a >kernel driver temporarely, that would allow me to use the "KeSetTimer" up >to a milli-second accuracy ?

Message 4 of 9

21 Mar 02 16:03

ntdev member 4101

xxxxxx@bsquare.com

Join Date:

Posts To This List: 143

Re: Changing Timer Resolution from within Kernel drivers

This is a really bad idea for a couple of reasons. First, this implies looping, which if done at DISPATCH_LEVEL holds off every other DISPATCH_LEVEL operation on this CPU while your loop is in progress. This wouldn't work for this application to well, unless I am missing something here. Second, there is no good way for your driver to determine what the HAL is determining here, as the HAL is using platform specific calls to do this, (read asm). So, you could make it work on say an x86 platform, but as soon as you go to an IA64 platform you are screwed. That is why it is in the HAL. Also, KeStallExecutionProcessor does nothing to prevent interrupts, it just loops. It doesn't even prevent preemption if called at < DISPATCH_LEVEL. -- Bill McKenzie "Ed Lau" <xxxxx@midcore.com> wrote in message news:25309@ntdev... Here's a snippet taken from a previous reply to another post (the subject was "atapi.sys hangs CPU for many seconds") which bay be of intrest: "I think that KeStallExecutionProcessor runs with interrupts disabled, so the IRQL would be 31. Just disassemble the function; it's pretty small. I looked at it years ago to figure out how it did the high-resolution timing. It's kinda clever; it measures how many of a given loop iteration it can execute in 1/18th of a second or whatever at bootup time, and then scales that down to the appropriate number of loops in the specified number of microseconds. (Thus, there's no timer actually involved when you call it.)" You might be able to use the same kind of logic in your driver to obtain higher resolution timing, depending on you exact needs. Regards, Ed Lau MidCore Software, Inc. 900 Straits Tpke Middlebury, CT 06762 www.midcore.com ----- Original Message ----- From: Ghijselinck To: NT Developers Interest List Sent: Thursday, March 21, 2002 6:30 AM Subject: [ntdev] Changing Timer Resolution from within Kernel drivers I'm currently developing a dedicated kernel driver for an I2C interface card for which I need to set timers with milli-seconds accuracy. I know about the existence of the "timeBeginPeriod" and its undocumented native API counterpart "NtSetTimerResolution" to change the default 10 mS granularity. However, both procedures cannot be used from within kernel drivers ( or ? ). Does anyone know about a way to increase the timer resolution from within a kernel driver temporarely, that would allow me to use the "KeSetTimer" up to a milli-second accuracy ? --- You are currently subscribed to ntdev as: xxxxx@midcore.com To unsubscribe send a blank email to %%email.unsub%% --

Message 5 of 9

21 Mar 02 16:46

ntdev member 542

xxxxxx@storagecraft.com

Join Date:

Posts To This List: 2446

Re: Changing Timer Resolution from within Kernel drivers

> granularity. However, both procedures cannot be used from within kernel > drivers ( or ? ). Does anyone know about a way to increase the timer > resolution from within a ExSetTimerResolution. Max

Message 6 of 9

22 Mar 02 03:03

Christiaan Ghijselinck

xxxxxx@Skynet.be

Join Date: 21 Mar 2002

Posts To This List: 436

Re: Changing Timer Resolution from within Kernel drivers

Thanks Stephan, I will try it out. However, the call is not available in the NT40 DDK version of Ntoskrnl.lib. Any idea if the library code within the W2000 version would work on NT40, or better, which kernel functions are exactly executed ? Christiaan

Message 7 of 9

24 Mar 02 02:33

ntdev member 5240

xxxxxx@yahoo.com

Join Date:

Posts To This List: 67

Re: Changing Timer Resolution from within Kernel drivers

The right way to do this is to add timers to your hardware and have them generate interrupts. If you can't, you are likely screwed. Windows is not real-time. Even if you get it to work on your machine, it might fail on others in different configurations. > ----- Original Message ----- > From: Ghijselinck > To: NT Developers Interest List > Sent: Thursday, March 21, 2002 6:30 AM > Subject: [ntdev] Changing Timer Resolution from within Kernel drivers > > > > I'm currently developing a dedicated kernel driver for an I2C interface > card for which I need to set timers with milli-seconds accuracy. I know <...excess quoted lines suppressed...> __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/

Message 8 of 9

24 Mar 02 23:35

Dave Harvey

xxxxxx@syssoftsol.com

Join Date: 24 Feb 2002

Posts To This List: 59

Re: Changing Timer Resolution from within Kernel drivers

"Ntdev Reader" <xxxxx@yahoo.com> wrote in message news:25437@ntdev... > > The right way to do this is to add timers to your hardware and have > them generate interrupts. If you can't, you are likely screwed. > Windows is not real-time. Even if you get it to work on your machine, NT is not hard real time, where you you've got some machine tool arm moving at 20 MPH, and you *must* get the CPU in 2 milliseconds to *stop* it or the machine will topple over.... But it is good enough to support Voice Over IP telephone calls, where the round trip delay (phone to phone and back again) must be less than 0.25 seconds. To do this, you need to run your threads at a real time priority level, which means that can lock up the machine if you have bugs such as infinite loops (unless you are looking for starvation of lower priority threads). You also must avoid poor quality drivers and hardware that break the rules on the systems where you need soft real time behavior. The default timer interupt of 10 (or 15) ms is often too long, and setting the system down to 1 ms is reasonable. The problem with trying to set it from the kernel is the interaction with other products that may be trying to do the same time. > it might fail on others in different configurations. But more hardware interrupts are not going to fix the cases where it fails, because the known cases are where video cards lock up the system bus when their FIFOs fill, or other drivers stay in their ISRs for too long. Configuration restrictions are necessary to ensure real-time behavior [ assuming that you are not willing to evolk the wrath of the list by patching the interrupt vectors for the rest of the devices.] -DH PS. There real-time thread priorities are there to do soft real time, and they work. The comments recommending that you don't use them are probably because MS has done too many support calls due to buggy real time code. > > > ----- Original Message ----- > > From: Ghijselinck > > To: NT Developers Interest List > > Sent: Thursday, March 21, 2002 6:30 AM > > Subject: [ntdev] Changing Timer Resolution from within Kernel drivers > > > > > > <...excess quoted lines suppressed...>

Message 9 of 9

25 Mar 02 00:40

ntdev member 5240

xxxxxx@yahoo.com

Join Date:

Posts To This List: 67

Re: Changing Timer Resolution from within Kernel drivers

Of course, if other drivers disable your interrupts you are out of luck. My point was that if you have your own interrupt you can (1) fire it precisely when you need and (2) average interrupt latency is lower than DPC (KeSetTimer) latency and you can handle time-critical stuff in the ISR directly. So, hardware timers are in order. This is a very general advice, but the original poster can't really hope for something more, for he specified neither his time requirements nor whether he has control over the hardware design. --- Dave Harvey <xxxxx@syssoftsol.com> wrote: > > "Ntdev Reader" <xxxxx@yahoo.com> wrote in message news:25437@ntdev... > > > > The right way to do this is to add timers to your hardware and have > > them generate interrupts. If you can't, you are likely screwed. > > Windows is not real-time. Even if you get it to work on your machine, > NT is not hard real time, where you you've got some machine tool arm > moving at 20 MPH, and you *must* get the CPU in 2 milliseconds to > *stop* it or the machine will topple over.... > <...excess quoted lines suppressed...> __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/

Posting Rules
You may not post new threads You may not post replies You may not post attachments	You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 02:44.

Contact Us - Osr Online Homepage - Top