Just wrote my first WDM driver for a customized PCMCIA card (I/O range mapped) running on Windows 2000. It is much slower than my VxD driver for Windows 9x (1.5-3 times slower).
The user mode program needs to read and write the card very frequently through DeviceIoControl calls. The typical size of reads and writes is less than 512 WORDS. I was trying to determine the overhead caused by DeviceIoControl for a date transfer of 512 WORDS (both input and output data size is 512 WORDS) through the following steps:
- call the DeviceIoControl in user program;
- do nothing but necessary buffering or mdl mapping in the corresponding kernel mode driver function.
- return to user program.
Here is the time (in micro-seconds) of the DeviceIoControl function call I obtained from three types of data buffering on 750MHz and 800MHz laptops.
Buffered I/O Direct I/O Neither I/O
750MHz 156 160 150
800MHz 96 98 92
Do those numbers make sense? This result does not include any hardware access. If the user program does thousands or millions of DeviceIoControl calls, this overhead will be a lot! Is there anything I might have missed?
Thanks,
Wendy
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I don’t remember the numbers, but one of the examples I have in a little
demo package I use when I go show DriverStudio to my customers is a little
driver that does nothing but return a fortune string when called. I can
choose between asking the driver to return it with a Read and with an
IoControl, and I then run through the driver a few thousand times each, and
measure the driver performance with our TrueTime. I found a difference in
timing of several to one in favor of the Read, that is, IoControl seems to
be real slow !
Alberto.
-----Original Message-----
From: xxxxx@agere.com [mailto:xxxxx@agere.com]
Sent: Thursday, October 11, 2001 7:20 AM
To: NT Developers Interest List
Subject: [ntdev] DeviceIoControl overhead
Just wrote my first WDM driver for a customized PCMCIA card (I/O range
mapped) running on Windows 2000. It is much slower than my VxD driver for
Windows 9x (1.5-3 times slower).
The user mode program needs to read and write the card very frequently
through DeviceIoControl calls. The typical size of reads and writes is less
than 512 WORDS. I was trying to determine the overhead caused by
DeviceIoControl for a date transfer of 512 WORDS (both input and output data
size is 512 WORDS) through the following steps:
- call the DeviceIoControl in user program;
- do nothing but necessary buffering or mdl mapping in the corresponding
kernel mode driver function.
- return to user program.
Here is the time (in micro-seconds) of the DeviceIoControl function call I
obtained from three types of data buffering on 750MHz and 800MHz laptops.
Buffered I/O Direct I/O Neither I/O
750MHz 156 160 150
800MHz 96 98 92
Do those numbers make sense? This result does not include any hardware
access. If the user program does thousands or millions of DeviceIoControl
calls, this overhead will be a lot! Is there anything I might have missed?
Thanks,
Wendy
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
With an overhead of 100 uSeconds an application can make 10,000 calls a second. Yes, these are the sort of numbers I expect. Many years ago I did the same sort of experiment with NT 3.51 and a slower CPU, but I still was able to process several thousand DeviceIoControl function calls per second.
I can believe your WDM driver is slower than a Vxd on the same machine. Windows 9x provides less protection and less driver framework and is therefor faster. But faster isn’t always better.
I believe video drivers can provide some direct memory access functionality to bypass this overhead.
Larry
-----Original Message-----
From: xxxxx@agere.com [mailto:xxxxx@agere.com]
Sent: Thursday, October 11, 2001 7:20 AM
To: NT Developers Interest List
Subject: [ntdev] DeviceIoControl overhead
Just wrote my first WDM driver for a customized PCMCIA card (I/O range mapped) running on Windows 2000. It is much slower than my VxD driver for Windows 9x (1.5-3 times slower).
The user mode program needs to read and write the card very frequently through DeviceIoControl calls. The typical size of reads and writes is less than 512 WORDS. I was trying to determine the overhead caused by DeviceIoControl for a date transfer of 512 WORDS (both input and output data size is 512 WORDS) through the following steps:
- call the DeviceIoControl in user program;
- do nothing but necessary buffering or mdl mapping in the corresponding kernel mode driver function.
- return to user program.
Here is the time (in micro-seconds) of the DeviceIoControl function call I obtained from three types of data buffering on 750MHz and 800MHz laptops.
Buffered I/O Direct I/O Neither I/O
750MHz 156 160 150
800MHz 96 98 92
Do those numbers make sense? This result does not include any hardware access. If the user program does thousands or millions of DeviceIoControl calls, this overhead will be a lot! Is there anything I might have missed?
Thanks,
Wendy
You are currently subscribed to ntdev as: xxxxx@diebold.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> I can believe your WDM driver is slower than a Vxd on the same machine. Windows 9x
provides less protection and less driver framework and is therefor faster.
Depends on tasks. On FS-intensive tasks, Win9x is much slower then NT due to NT’s cache manager being much more smart.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com