Poor IDE performance on KT333

  • Thread starter Thread starter kalabp
  • Start date Start date
K

kalabp

My basic system specs are this: Athlon XP 2000+, MSI KT3 Ultra2, 768 MB
RAM. I have a Maxtor 6Y080L0 as primary master, LG CD-RW as secondary
master, and a Maxtor 6Y060L0 in a removable rack as secondary slave.

I am running Win2K with SP4. When I run the FC-Test program
<http://www.xbitlabs.com/articles/storage/display/fc-test.html> on my
drives, I get only about 5 MB/sec write speed, and 24 MB/sec read speed.

I have no clue why the drives are so slow.
- they are recognized as mode UDMA 6 in the BIOS.
- I have installed the latest 4-in-1 drivers and the Via IDE miniport
driver. The IDETOOL supplied by Via with the miniport driver shows the
drives as running in UDMA 6 (ATA 133) mode.
- the drives show up in Device Manager as SCSI drives. The only options
I can change there are to disable tagged queueing and synchronous
transfers (I have not disabled either).

Another data point is that I have used PowerQuest Drive Image 2002 to do
disk-to-disk copies on this system. DI 2002 has reported data transfer
rates over 1000 MB/min, so the drives are clearly capable of writing at
more than 5 MB/sec in DOS mode. This suggests to me that the performance
problem is somewhere in Win2K/Via drivers.

Any ideas what to try next?

More fun stuff: when I tried to uninstall the Via driver, I got the
INACCSSIBLE BOOT DEVICE blue screen. Reverting to the "last good
configuration" got me back in with the Via drivers still installed. I
presume this is something to do with the fact that Win2K thinks my IDE
drive is now SCSI, so if I uninstall the Via driver it gets all confused?
 
Mixing hard drives and CD-ROM, CD-RW or DVD drives on the same controller
slows down the hard drive.
Does your KT333 come with highpoint raid controllers ?
I believe a highpoint controllers show up as a SCSI controller in device
manager ?
 
Rod said:
Bullshit. And it clearly doesnt slow down Drive Image.
Furthermore, the 80GB drive is the only device on the primary IDE
channel, the CD-RW and the backup disk are together on the secondary.No RAID controller, no SCSI controller. Apparently the pseudo-SCSI disk
is a "feature" of the Via IDE miniport driver. Either way, it doesn't
seem to help or hurt the system. I have seen some people complain on the
Via forums that they could not use their CD-R with the miniport driver,
but that does not seem to be a problem here.

The other thing which comes to mind is if the disk is performing write
verification all the time. According to an article at Xbit-labs, the
Maxtors do write verify each sector for the first 10 reboots or
something like that, so I'll try Maxtor's utility to turn off write
verify and see if that does anything good.

Just out of curiosity I tried FC-Test on another machine (Dell with a
Seagate Barracuda ATA), and that produced more reasonable results (20
MB/sec or so for create and close to 40 MB/sec for reading, IIRC).
 
I don't know if this helps, but I suspect that drives claiming to be ATA133
are over optimistic. 133 is the burst capability. Sustained transfer rates
are much less.

Using a Matrox benchmarking tool, I can only get 42 MB/s from my 133 drives
and 12 MB/s from my old 66 drive.

If you're running Norton AV, turning off auto-protect speeds up the system
noticeably.

cw
 
I don't know if this helps, but I suspect that drives
claiming to be ATA133 are over optimistic.

They're just claiming to support ATA133 and do support it.

They imply that thats better than ATA100 when in fact its the
drive physical characteristics, mostly the rotation rate and
sectors per track that determines the thruput and whether
ATA100 is plenty fast enough for that particular drive.
133 is the burst capability. Sustained transfer rates are much less.
Correct.

Using a Matrox benchmarking tool, I can only get 42 MB/s
from my 133 drives and 12 MB/s from my old 66 drive.

And that difference is mostly due to the different
physical characteristics of the two drives.
If you're running Norton AV, turning off auto-protect
speeds up the system noticeably.

It'd be a hell of a lot more surprising if it didnt.
 
In case anyone is still following this thread and cares about the
outcome, I found the answer on the MSI forums. The problem was caused by
the BIOS setting "Detect CPU HALT Command" being enabled. After
disabling this setting in the BIOS, the disk read and write performance
as measured by FC-Test improved considerably to the levels I would
expect of a modern hard disk. A Drive Image backup also ran about twice
as fast as before, creating images using "normal" compression at over
1000 MB/min instead of 500 MB/min (I haven't tried the disk copy
operation to see if that has speeded up as well, but I'm very happy with
backups taking half the time they used to).

Thanks,
Peter
 
Back
Top