Kernel Driver High Frequency Timer

NTDEV
1

Hello,

I am trying to implement a periodic timer in a KDMF driver that would execute memory reads from an FPGA once every 2 milliseconds.
I was planning on using a kernel timer and triggering a DPC to read the data.
I have a timer and DPC running and it is working fine except I can not get the thing to run any faster than about one iteration every 15 mSec.
I have tried using KeSetTimerEx with a periodic timer and another version with KeSetTimer being called in the DPC to fire the next one, but everything seems to run at a max speed of 15.6 mSec no matter how much faster I set it.

I thought about using a kernel thread, but documentation on those say they run at PASSIVE_LEVEL so I am assuming a DPC would be much faster and more accurate.

I have found multi-media API documentation that says timers can execute as quickly as 1 mSec.

How do you do that in a driver???

Thanks.

2

Have your FPGA issue an interrupt every 2 ms. As simple as that.

You can also use ExSetTimerResolution.

3

Thanks for your reply Alex.

Unfortunately an interrupt is not an option according to our hardware people.

The ExSetTimerResolution is interesting though. I called it with a high value to just read the current value and I get 15.6 mSec resolution from my XP box as measured.

Only weird thing is I called it with a value of 300,000 (30mSec) for the DesiredTime value and it returned my time above but then set the resolution to 9766… so my speed increased significantly…

Not quite what I expected, but it gives me something to look at…

4

>

Hello,

I am trying to implement a periodic timer in a KDMF driver that would
execute memory reads from an FPGA once every 2 milliseconds.
I was planning on using a kernel timer and triggering a DPC to read the
data.
I have a timer and DPC running and it is working fine except I can not get
the thing to run any faster than about one iteration every 15 mSec.
I have tried using KeSetTimerEx with a periodic timer and another version
with KeSetTimer being called in the DPC to fire the next one, but
everything seems to run at a max speed of 15.6 mSec no matter how much
faster I set it.

I thought about using a kernel thread, but documentation on those say they
run at PASSIVE_LEVEL so I am assuming a DPC would be much faster and more
accurate.

This is a common problem. Have your device generate an interrupt at the
desired interval. No other solution will be guaranteed to be robust
enough (my coauthor tells of such a device he had to program, and getting
it to run in 2ms intervals was a nightmare and seriously imppacted overall
system performance, which fortunately didn’t matter because when this
device was running, it was the ONLY thing the system had to do [and it was
the ONLY thing the system COULD do].

The appropriate solution here is a hardware solution, not a software
solution.
joe

I have found multi-media API documentation that says timers can execute as
quickly as 1 mSec.

How do you do that in a driver???

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

5

> How do you do that in a driver???

ExSetTimerResolution

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

> Unfortunately an interrupt is not an option according to our hardware people.

Your hardware people are under wrong attitude that any possible hardware can be supported by Windows.

It is not so.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

The consensus seems to be a hardware solution and I am in complete agreement… I will bring the issue up again…I don’t know about getting an interrupt wired in but maybe a bigger input FIFO would be ok with them…

Thanks for the help.

8

xxxxx@peoplepc.com wrote:

I have tried using KeSetTimerEx with a periodic timer and another version with KeSetTimer being called in the DPC to fire the next one, but everything seems to run at a max speed of 15.6 mSec no matter how much faster I set it.

Right. The operating system’s basic timer interrupt runs at about 64
Hz. That’s when the scheduler runs to re-evaluate priorities and choose
the next thread to run. That’s also when the timer list is evaluated.

I have found multi-media API documentation that says timers can execute as quickly as 1 mSec.

They can, IF you reprogram the fundamental timer interrupt, using
ExSetTimerResolution. You need to realize that this impacts performance
system-wide. You’ll now be invoking the scheduler 1,000 times per
second instead of just 64 times per second. For short sessions, that’s
OK, but it’s a mistake to change that setting permanently.

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

9

>You’ll now be invoking the scheduler 1,000 times per second instead of just 64 times per second.

I don’t think so. Scheduler will only be invoked when a timeslice on the current processor expires, which is not the same as the next timer interrupt, or when a candidate thread gets to the ready list, which doesn’t depend on the timer frequency either.

10

xxxxx@broadcom.com wrote:

> You’ll now be invoking the scheduler 1,000 times per second instead of just 64 times per second.
I don’t think so. Scheduler will only be invoked when a timeslice on the current processor expires, which is not the same as the next timer interrupt, or when a candidate thread gets to the ready list, which doesn’t depend on the timer frequency either.

Well, the difference is a little subtle. Clearly, there has to be a
re-evaluation of the current threads and the ready list, otherwise it
wouldn’t do any good to set a shorter timer. Barring a timer
expiration, you won’t get a thread switch at every hit, but there’s
still going to need to be some kind of re-evaluation every time.

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

11

It is a common delusion among hardware designers that, since they can
figure out how to program the device on a standalone desktop under MS-DOS,
that their design is sufficient. They have no understanding about real
operating systems and their limitations. THEREFORE, it can realidy be
said that any hardware design that does not include a review by a
competent software developer in the target operating systems can be a
flawed and unsupportable design. Any company that allows hardware design
to take place without such review can be thought of as somewhere between
stupid and incompetent. A hardware designer that assumes that a design
which has not been reviewed by software people will work is not qualified
to hold a position as a hardware designer.

You would not believe (actually, some of you WOULD believe) how many bad
designs I’ve reviewed in the last 40 years. Most of the bad decisions I
pointed out were justified by saying “But THE SOFTWARE will handle that”
without any definition of what THE SOFTWARE is. One computer architecture
could not be debugged because it was assumed that exactly ONE instance of
“THE SOFTWARE” could track the stack, and there was no way to read the
stack pointer register (you could set it, but not read it!) The fact that
the operating system, the application, and the debugger were orthogonal
instances of “THE” software completely escaped them.

If the hardware people can’t give you an interrupt, they screwed the
pooch. They’ve built a device which cannot survive in real environments.

A hardware engineer position should have a requirement of having had a
driver course, or two (such as linux and Windows). In one course I
taught, the four students across one row were the hardware designer, the
firmware programmer, the driver-writer-to-be and the application
developer. THAT product will be successful! Every one of them said that
they had learned something critical to the success of the project.

When it comes to poor hardware design, show no mercy.
joe

> Unfortunately an interrupt is not an option according to our hardware
> people.

Your hardware people are under wrong attitude that any possible hardware
can be supported by Windows.

It is not so.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

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

> operating systems and their limitations. THEREFORE, it can realidy be

said that any hardware design that does not include a review by a
competent software developer in the target operating systems can be a
flawed and unsupportable design.

+1.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

13

On 08-Aug-2012 10:11, Maxim S. Shatskih wrote:

> operating systems and their limitations. THEREFORE, it can realidy be
> said that any hardware design that does not include a review by a
> competent software developer in the target operating systems can be a
> flawed and unsupportable design.

+1.

For many specific projects, this is relative and depends (actually
this may be fine in a dedicated system that does fixed workload and
doesn’t need to scale, or be extremely low power).

/* And sloppy hardware designs are income opportunities to people like
myself. It’s delight to watch h/w folks and their PMs jumping
back to life out of total desperation :slight_smile: */
– pa

14

>Well, the difference is a little subtle. Clearly, there has to be a re-evaluation of the current threads and the ready list, otherwise it wouldn’t do any good to set a shorter timer. Barring a timer expiration, you won’t get a thread switch at every hit, but there’s still going to need to be some kind of re-evaluation every time.

I haven’t had Windows source code access privilege, but a reasonable way to implement timer handling would be to keep a sorted list of timer objects and then you only care about the closest timer expiration. That check is a single trivial comparison per timer interrupt. The timeslice expiration is just another timer or a single value (per processor) in a known location.

Thread switch re-evaluation is done when a thread changes its runnable state, and doesn’t have to be done at timer interrupts.