About a mouse device's sample rate

NTDEV
1

(Sorry, I couldn’t find a better title.)

Hello,

I timestamp incoming mouse packets (DISPATCH_LEVEL) using KeQueryPerformanceCounter and checked the results with a USB HID mouse.
The device has a bInterval value of 8, so it has an anisochronous sample rate of 8 ms.

When moving the mouse sufficiently fast, the time delta would be ~ 7.95 ms on average.

I know, it doesn’t really matter, but would you assume that the “polling” mechanism is slightly off or that the time measurement is slightly erroneous?

(Of course, according to several physical theorems, both cannot be infinitely accurate.)

Thanks.

2

Both. Also remember that the DPC in which the io is completed could be delayed due to other DPCs ahead of it in the queue.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hushmail.com
Sent: Sunday, September 16, 2007 10:28 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] About a mouse device’s sample rate

(Sorry, I couldn’t find a better title.)

Hello,

I timestamp incoming mouse packets (DISPATCH_LEVEL) using KeQueryPerformanceCounter and checked the results with a USB HID mouse.
The device has a bInterval value of 8, so it has an anisochronous sample rate of 8 ms.

When moving the mouse sufficiently fast, the time delta would be ~ 7.95 ms on average.

I know, it doesn’t really matter, but would you assume that the “polling” mechanism is slightly off or that the time measurement is slightly erroneous?

(Of course, according to several physical theorems, both cannot be infinitely accurate.)

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

3

xxxxx@hushmail.com wrote:

(Sorry, I couldn’t find a better title.)

Hello,

I timestamp incoming mouse packets (DISPATCH_LEVEL) using KeQueryPerformanceCounter and checked the results with a USB HID mouse.
The device has a bInterval value of 8, so it has an anisochronous sample rate of 8 ms.

When moving the mouse sufficiently fast, the time delta would be ~ 7.95 ms on average.

I know, it doesn’t really matter, but would you assume that the “polling” mechanism is slightly off or that the time measurement is slightly erroneous?

How are you converting the KQPC cycle count to milliseconds? Are you
assuming that your 3.2 GHz processor runs its clock at exactly
3,200,000,000 cycles per second? Crystals just aren’t that accurate.

If you are running a stock uniprocessor HAL (where the KQPC frequency is
in the MHz range), then you are actually reading the countdown value of
the interval timer, which requires multiple I/O instructions that can
take a long and somewhat variable amount of time.

USB’s polling is controlled by the master USB clock. The accuracy of
that clock is defined by the standard to be 0.05%, which is 0.5us per
ms. The mismatch here has to be in the measurements.

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

4

Thanks for all replies.

Tim Roberts wrote:

How are you converting the KQPC cycle count to milliseconds?
I convert the tick count to a double and divide it by PerformanceFrequency.

I use an ACPI uniprocessor HAL, PerformanceFrequency is 3579545, so its using the ACPI PM timer.