Thanks for your inputs, Philip.
Our systems are working in harsh environment (vibrations, heat, 24x7 use) and we recently experienced a string of hard drive failures at customer sites that we believe forced Windows to switch to PIO (probably a bad batch of drives). We were hoping to add a quick check in our diagnostic tool to detect it .
Our application is extremely CPU and disk intensive and doing disk PIO will be too much. If I remember correctly, the reason why IDE drives were chosen over SCSI is that SCSI didn’t offer the huge capacity that we needed.
I already did try IRP tracker before posting but I was hoping that the IOCTL’s were documented. I now know they’re not!
Patrick
Patrick Laniel
Technical Lead, Driver Development
Visual System Engineering
CAE
Tel: (514) 341-6780 ext. 3886
Fax: (514) 340-5539
Subject: RE:Obtaining the current IDE ATA transfer mode
From: Philip D Barila
Date: Fri, 17 Jun 2005 09:35:52 -0600
X-Message-Number: 9
What problem are you really trying to solve that you think you need to know
the transfer mode of these devices?
How do you know you can’t afford the CPU hit? Do you have a CPU bound
foreground app running 24x7? Do you have unreasonable latency requirements
on something else?
Keep in mind that the reason the OS throttles down the ATA transfer rate
from UDMA 5 to 4 to 3 to PIO, is that errors are detected. If your
hardware is fully functional, the only other cause for Windows to do that
is a flaky cable. If you have this happening more frequently than once in
a blue moon, find yourself a new cable vendor with better QA. If it’s the
hardware failing, you need to replace it anyway. Since you are part of a
package, this is a matter of QA for the package assembler, more than
anything else.
I don’t think the IOCTLs that the property page DLL (storprop.dll?) and
atapi.sys share are documented, but you might check the DDK, as I not too
sure about that. If they aren’t, you could probably get them from
Microsoft PSS if you make a sound business case for having them. If that
fails, you could try sorting them out yourself. Do you have a
source-license? Just look there. If not, you could probably do it with a
filter. I don’t know if IrpTracker is sufficient for this, or if you will
need something more focussed.
If your CPU utilization is really this critical, then perhaps you might
need to consider that an embedded SCSI adapter might be appropriate, for
the reason that modern SCSI controllers don’t do PIO, they just DMA at
whatever speed is running on the bus. So even if the OS throttles down the
transfer speed to minimum, the CPU hit is still approximately zero.
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842