poor ide performance?

[Rambler]

got a "problem" here. i've got 80G older Barracuda IV hdd and even older 30G Barracuda II drive.
my problem is that when i copy from drive to drive, i get reasonable transfer rate 10-15MB/s or so. but when i copy from one partition to another on the 'cuda IV hdd, i get 5MB/s. I know u get lower performance and that it's an older driver, but 5MB/s seems bit too low. Oh and while copying i get like ~<10% cpu usage, but system is not too responsive - like the transfer chokes everything - responsive i mean even switching between apps - can take 10s or more.

the thing is i don't think i had this crappy performance with my old duron 800MHz 2 years ago.

specs: P4 2.4@2.85 (HT on), 512MB DDR333

any ideas?

 

[zandor]

It's normal that you'll get (much) less speed copying a file to the same disk. I often find it can be quicker to copy a file to a different disk and back to the original than to copy to the same disk. OS copy commands are generally really dumb about using system memory to buffer the copy. They only use a little, so the drive has to seek a lot. xcopy in DOS was actually smart about this and would use as much of your 640k system ram as was available, but Windows explorer, UNIX cp, etc. don't. At best you should get about half the x-fer rate of the drive on a copy, and usually a lot less.
For you fellow UNIX geeks out there, if you're copying a directory structure to the same drive the quickest way can be to tar it up to a different drive then untar it to the target location. Plus you can do it all on one command line. ie-

tar -cf file_on_other_drive.tar; cd target_dir; tar -xf file_on_other_drive.tar

 

[Rambler]

well yes, i know i should expect much lower perf., it's just it seems somewhat low even by my standards
and what bothers me most is how the system becomes unresponsive, forcing me to wait till the transfer is over, because i can't do much more while it's in progress :/

 

[Canon]

The only thing I can think of is make sure your IDE controlllers are set for DMA instead of PIO mode in device manager.

I can usually do other things while copying but my system performance is certainly substantially hindered while copying and it takes a quite a while. Make sure you don't need to actually copy (if you were intending on deleting the source anyhow), it's much quicker to do a cut and paste instead, takes a fraction of the time.

 

[zandor]

The only thing I can think of is make sure your IDE controlllers are set for DMA instead of PIO mode in device manager.

You mean PIO instead of DMA right?
Of course, if his CPU usage is at 10%, that sounds like DMA to me...

 

[unhappy_mage]

tar -cf file_on_other_drive.tar; cd target_dir; tar -xf file_on_other_drive.tar

I dunno, I'd use something like this:

find /source -depth -print | cpio -pdmav /dest

it should be DMA not PIO, DMA transfers are a jillion times faster.

latest ide drivers? other than that... i dunno.

 

[Rambler]

Yeah, checked many times, all controlers are set to udma.
If that helps, cfg is as follows:
ide1: BarrIV(udma5)/BarrII(udma4) (master/slave)
ide2: DVD burner(udma2), CDROM(udma2) (master/slave)

Well, this shouldn't be an issue as i'm not complaining about poor hdd-hdd or dvd/cd-hdd performance.

Maybe i just need new faster hdd, which i can't afford right now.
It's just strange how big bottleneck of my system these hdds are :/

 

[Ice Czar]

It's normal that you'll get (much) less speed copying a file to the same disk.

^

just a quick cut and paste
http://hardforum.com/showthread.php?t=754424 > http://www.hardforum.com/showthread.php?s=&threadid=741512

--------------------------------------------------------------------------------------------------------------------
Optimizing Physical Configuration
being on the same channel there are a few considerations

IDE\ATA\ATAPI is sequential
meaning first the HDD reads a part of the file until the HDD's Cache is full then writes it to the Second HDD,
then that repeats each taking its own turn
then its unlikely its reading the file from a single location, its probably fragmented, and when it writing it, its also writing it to multiple locations, that introduces the latency and access times of both drives into it

if your going to be transfering alot of data inbetween two HDDs on a regular basis, its best if they are on their own channels, writing from a HDD to a Optical drive is alot better, the optical can only deal with a maximum of 33MB/s Burst (UDMA mode2) whereas the HDD is probably at UDMA mode5 100MB/s burst (50>30MB/s Sustained), in short the sequential issues arent enought to effect the burn speed with modern software (and reads arent really an issue either) both cant saturate the bus

of course those are just interface speeds and are not the sole consideration of HDD performance > As the Disc Spins @ Lost Circuits

there is a myth about putting optical drives on the same channel as HDDs, it is just that a myth, but it keeps getting reinforced by the way Windows deals with ATA\ATAPI issues
basically with Independent Device Timing two devices (master\slave) both transfer their data at their own highest speed, but, they both either have to be PIO (which is glacially slow) or UDMA, if one defaults to PIO because of some issue, Windows will default the other as well. There was a time when CDROMs where only PIO, and HDDs where DMA, for that period of history you didnt want to share a channel, but modern opticals are UDMA mode2 so there is rarely any issue

some of the reasons a device might default to PIO
DMA Mode for ATA/ATAPI Devices in Windows XP
IDE ATA and ATAPI Disks Use PIO Mode After Multiple Time-Out or CRC Errors Occur

however if possible it is ideal
(for data integrity if nothing else)
to have each device as a master on its own channel

whenever possible consider from what source to what target the large files are being transfer on a regular basis,
and try to adapt your physical configuration to accommodate that
-----------------------------------------------------------------------------------------------------------------------------

all that much worse when copying from one location to another on a single drive
fragmentation, caches, seek, latency and arm repositioning all come into play
the workload cant be split between two drives, or across two channels
the fragmentation level of the source and the ability to write the file in contigious space on the target partition makes a big difference all else being equal however