Question about high performance timers on XP systems

NTDEV
1

I have the need for a timer that will fire at a rate of 400 Hz, on an XP
system. On my system, the KeQueryTimeIncrement call tells me my system
timer only has a granularity of about 64 Hz.

To complicate things a bit further, this driver will need to run on a wide
range of laptops, all of which I assume could have different system timer
granularities.

My driver is also performing high speed isochronous data transfer over USB.
I’ve explored the possibility of checking the system time as part of the
processing of the isochronous packets, but have found that the granularity
of the KeQuerySystemTime is only 10 msec, which isn’t small enough. I could
possibly use KeQueryPerformanceCounter, but the documentation indicates
calling this too frequently would degrade system performance.

The only solution I seem to see, is to have another isochronous pipe, which
will return data to my driver at a rate of exactly 400 Hz (a hardware timer
in the device can do this). This pipe would be acting purely as a timer
for my driver. I don’t think this is a very clean solution, so was
wondering if anybody else has another idea?

thanks,
Jeff Helmers

2

Calling KeQueryPerformanceCounter once at every completion of your USB
transactions should be fine.
Just do not call it in a tight loop to do short timeouts.

Norbert.

“Out of my mind. Back in five minutes.”
---- snip ----

3

Jeff Helmers wrote:

I have the need for a timer that will fire at a rate of 400 Hz, on an XP
system. On my system, the KeQueryTimeIncrement call tells me my system
timer only has a granularity of about 64 Hz.

To complicate things a bit further, this driver will need to run on a wide
range of laptops, all of which I assume could have different system timer
granularities.

No. The timer granularity is independent of the hardware. Well, that’s
not technically true; the real situation is that the hardware is all
identical.

Depending on your HAL, you’ll get either 64 Hz or 100 Hz granularity.
The system timers do not use hardware; they are strictly a software
feature, updated during a context switch. Thus, the only way to
increase the timer rate is to increase the context switch frequency, and
that’s expensive.

My driver is also performing high speed isochronous data transfer over USB.
I’ve explored the possibility of checking the system time as part of the
processing of the isochronous packets, but have found that the granularity
of the KeQuerySystemTime is only 10 msec, which isn’t small enough. I could
possibly use KeQueryPerformanceCounter, but the documentation indicates
calling this too frequently would degrade system performance.

Your isochronous packets get a packet number. That’s a very accurate 8
kHz clock.

The only solution I seem to see, is to have another isochronous pipe, which
will return data to my driver at a rate of exactly 400 Hz (a hardware timer
in the device can do this). This pipe would be acting purely as a timer
for my driver. I don’t think this is a very clean solution, so was
wondering if anybody else has another idea?

Think about what you’re proposing here. USB is an entirely host-driven
bus. Your device cannot SEND anything on its own. It can only respond
to requests by the host. That means your 400 Hz idea will only work
because the host is ALREADY using a precision timer to ASK you for data
on a regular basis.

Use that precision timer. Your driver is already getting a packet (or
multiple packets) every millisecond. You can exploit that to do your
periodic processing.

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

4

Wow, that is right. Every 20 packets works out to the 400Hz timer I’m
looking for. You just saved us a bunch of work. Thanks!!!

Jeff

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Jeff Helmers wrote:
>
> >I have the need for a timer that will fire at a rate of 400 Hz, on an XP
> >system. On my system, the KeQueryTimeIncrement call tells me my system
> >timer only has a granularity of about 64 Hz.
> >
> >To complicate things a bit further, this driver will need to run on a
wide
> >range of laptops, all of which I assume could have different system timer
> >granularities.
> >
> >
>
> No. The timer granularity is independent of the hardware. Well, that’s
> not technically true; the real situation is that the hardware is all
> identical.
>
> Depending on your HAL, you’ll get either 64 Hz or 100 Hz granularity.
> The system timers do not use hardware; they are strictly a software
> feature, updated during a context switch. Thus, the only way to
> increase the timer rate is to increase the context switch frequency, and
> that’s expensive.
>
> >My driver is also performing high speed isochronous data transfer over
USB.
> >I’ve explored the possibility of checking the system time as part of the
> >processing of the isochronous packets, but have found that the
granularity
> >of the KeQuerySystemTime is only 10 msec, which isn’t small enough. I
could
> >possibly use KeQueryPerformanceCounter, but the documentation indicates
> >calling this too frequently would degrade system performance.
> >
> >
>
> Your isochronous packets get a packet number. That’s a very accurate 8
> kHz clock.
>
> >The only solution I seem to see, is to have another isochronous pipe,
which
> >will return data to my driver at a rate of exactly 400 Hz (a hardware
timer
> >in the device can do this). This pipe would be acting purely as a timer
> >for my driver. I don’t think this is a very clean solution, so was
> >wondering if anybody else has another idea?
> >
> >
>
> Think about what you’re proposing here. USB is an entirely host-driven
> bus. Your device cannot SEND anything on its own. It can only respond
> to requests by the host. That means your 400 Hz idea will only work
> because the host is ALREADY using a precision timer to ASK you for data
> on a regular basis.
>
> Use that precision timer. Your driver is already getting a packet (or
> multiple packets) every millisecond. You can exploit that to do your
> periodic processing.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

5

> The system timers do not use hardware; they are strictly a software

feature, updated during a context switch. Thus, the only way to
increase the timer rate is to increase the context switch frequency, and
that’s expensive.

No. The timer is updated on timer IRQ, which is not a context switch. It causes
a context switch only on quantum end situation, which occurs only on 100% CPU
load.

Your isochronous packets get a packet number. That’s a very accurate 8
kHz clock.

I would consider this solution as being the best.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com