Reason for different IDE performances between 2 internal drives?

[zigipha]

I have a win2k system, 1.8GHz P4 with 256 MB ram, with two internal
hard drives and a USB drive. I was doing a performance test by copying
a 388 MB file from the internal drives to the USB drive. One drive took
55 seconds, the other took 180 seconds. I was wondering why the 3x
difference

C drive: WD 40 GB drive, FAT32 formatted. Master disk on IDE ch 0. 20%
full, frag report shows free space has 0% fragmentation. I copied the
388 MB file from the D drive to the C drive to perform that test. 55
seconds to copy

D Drive: Seagate 120 GB, NTFS formatted. Slave drive on IDE ch 0. 77%
full. Frag report shows average fragments / file is 1.12. The 388 MB
files was originally on here, and I copied it from its original
location for the test. 180 seconds to copy.

The destination is a Seagate 160 GB USB, with USB 2.0. But that should
be irrelevant since I am wondering why the two internal drives perform
with over 3x difference in read times.

Thanks

 

[Rod Speed]

(e-mail address removed) wrote

I have a win2k system, 1.8GHz P4 with 256 MB ram, with two internal
hard drives and a USB drive. I was doing a performance test by copying
a 388 MB file from the internal drives to the USB drive. One drive
took 55 seconds, the other took 180 seconds. I was wondering why the
3x difference

C drive: WD 40 GB drive, FAT32 formatted. Master disk on IDE ch 0. 20%
full, frag report shows free space has 0% fragmentation. I copied the
388 MB file from the D drive to the C drive to perform that test. 55
seconds to copy

D Drive: Seagate 120 GB, NTFS formatted. Slave drive on IDE ch 0. 77%
full. Frag report shows average fragments / file is 1.12. The 388 MB
files was originally on here, and I copied it from its original
location for the test. 180 seconds to copy.

The destination is a Seagate 160 GB USB, with USB 2.0. But that should
be irrelevant since I am wondering why the two internal drives perform
with over 3x difference in read times.

Try HDTach and see if there is anything obvious with it.

Check that DMA is enabled on the Seagate.

 

[Eric Gisin]

I have a win2k system, 1.8GHz P4 with 256 MB ram, with two internal
hard drives and a USB drive. I was doing a performance test by copying
a 388 MB file from the internal drives to the USB drive. One drive took
55 seconds, the other took 180 seconds. I was wondering why the 3x
difference

C drive: WD 40 GB drive, FAT32 formatted. Master disk on IDE ch 0. 20%
full, frag report shows free space has 0% fragmentation. I copied the
388 MB file from the D drive to the C drive to perform that test. 55
seconds to copy

D Drive: Seagate 120 GB, NTFS formatted. Slave drive on IDE ch 0. 77%
full. Frag report shows average fragments / file is 1.12. The 388 MB
files was originally on here, and I copied it from its original
location for the test. 180 seconds to copy.

The file is likely very fragmented (typical with downloads).
The defrag summary should tell you how many fragments.
Delete the file, defrag, copy it from C, and try again.

 

[Rod Speed]

The file is likely very fragmented (typical with downloads).
The defrag summary should tell you how many fragments.
Delete the file, defrag, copy it from C, and try again.

Fragmentation shouldnt triple the copy time.

 

[zigipha]

I thought it might be frag, but it wasnt convienient to defrag, and the
other threads seem to indicate that defrag wasnt THAT big an issue. But
i might give it a shot. BTW other disks in the office offer 55 second
or below xfer times to a usb drive, so i know the 3 min is the
odditity.

I remember reading about some performance differences between primary
and secondary positions..was that myth, if not has that been resolved?

 

[Rod Speed]

(e-mail address removed) wrote

I thought it might be frag, but it wasnt convienient to defrag,

You could try deleting it from the Seagate
and copying it back from the WD.

and the other threads seem to indicate that defrag
wasnt THAT big an issue. But i might give it a shot.

I'd be amazed if it was that with the Seagate being 3 times slower.

BTW other disks in the office offer 55 second or below
xfer times to a usb drive, so i know the 3 min is the odditity.

Yeah, the most likely explanation if that DMA
isnt working on the Seagate for some reason.

The other possibility is a bad cable and
heaps of corrected retrys with the Seagate.

I remember reading about some performance differences between primary
and secondary positions..was that myth, if not has that been resolved?

Yes, that is certainly a myth.

 

[Folkert Rienstra]

(e-mail address removed) wrote


You could try deleting it from the Seagate
and copying it back from the WD.

Clueless, as always.

I'd be amazed if it was that with the Seagate being 3 times slower.

Of course you would. Layers of egg to be washed off of your face.

 

[Rod Speed]

Clueless, as always.

I told you your sig goes at the bottom, ****wit.

The reason for trying that is to minimise the fragmentation
of that file, instead of defragging the drive. Its unlikely to
help with the copy time but is easy to try.

Of course you would. Layers of egg to be washed off of your face.

Fragmentation aint gunna triple the copy time, ****wit.

Have fun explaining why only that drive is severely fragmented.

 

[zigipha]

I have a win2k system, 1.8GHz P4 with 256 MB ram, with two internal
hard drives and a USB drive. I was doing a performance test by copying
a 388 MB file from the internal drives to the USB drive. One drive took
55 seconds, the other took 180 seconds. I was wondering why the 3x
difference

C drive: WD 40 GB drive, FAT32 formatted. Master disk on IDE ch 0. 20%
full, frag report shows free space has 0% fragmentation. I copied the
388 MB file from the D drive to the C drive to perform that test. 55
seconds to copy

D Drive: Seagate 120 GB, NTFS formatted. Slave drive on IDE ch 0. 77%
full. Frag report shows average fragments / file is 1.12. The 388 MB
files was originally on here, and I copied it from its original
location for the test. 180 seconds to copy.

As a followup, I downloaded PassMark V5.0. For the C (good) drive, I
got 25.2 Mbyte/s seq read, 21.1 Mbyte/s seq write, and 3.0 Mbyte/s
random seek +r/w.

For the D(bad) drive, I got 2.4 Mbytes/ seq read, 2.3 Mbytes seq/write
and 2.5 Mbytes/s random seek r/w. I reran it again just to make sure.
The numbers were pretty awful.

I checked the bios settings; both drives had 32 bit mode on, PIO mode
on, block mode on and LBA on. There were no other settings for DMA
on/off.

So i substituted a 60 GByte Maxtor drive in place of the D drive, reset
the bios settings to auto to detect the drive and reran the PassMark
test. I got 31.2 MBytes seq read, 28.2 seq write and 4.7 random seek
r/w. So I figure the drive was bad.

But when I put in the Maxtor, the Iomega backup program, running on
automatic mode, saw all these new files, so I had to disable its
operation. I wondered if the Iomega was the cause (the Iomega monitors
the D drive, but not the C drive, for changes and saves the changed
files to the USB drive).

I put the old D drive, the seagate 120 GB, back in to D and reran the
test: 43.6 seq read, 43.0 seq write, 4.9 random seek. I didnt believe
it! But..to be sure..I turned the Iomega back on and rerant the test. I
essentially got the same results.

Powered the pc off, turned it back on, iomega was running, ran the test
and got 36 seq read, 35 seq write, 4.7 random r/w. This is under the
same conditions that gave me the bad results at the beginning. Just for
laughs I copied the 388 Mbyte file from disk to disk..took about 20
seconds.

So what happened? The only states that changed was a) the cables to the
drive plugged out and back in (with the maxtor in between) and b) the
bios was set to a different drive and back to the original.

Any thoughts? I'm betting the cable needed to be reseated.p

 

[Rod Speed]

(e-mail address removed) wrote:

As a followup, I downloaded PassMark V5.0. For the C
(good) drive, I got 25.2 Mbyte/s seq read, 21.1 Mbyte/s
seq write, and 3.0 Mbyte/s random seek +r/w.

For the D(bad) drive, I got 2.4 Mbytes/ seq read, 2.3 Mbytes
seq/write and 2.5 Mbytes/s random seek r/w. I reran it again
just to make sure. The numbers were pretty awful.

They are indeed, utterly obscene.

I checked the bios settings; both drives had 32 bit
mode on, PIO mode on, block mode on and LBA
on. There were no other settings for DMA on/off.

Sorry, you should be checking that in XP, not the bios.

So i substituted a 60 GByte Maxtor drive in place of the D drive,
reset the bios settings to auto to detect the drive and reran the
PassMark test. I got 31.2 MBytes seq read, 28.2 seq write
and 4.7 random seek r/w. So I figure the drive was bad.

But when I put in the Maxtor, the Iomega backup program,
running on automatic mode, saw all these new files, so I
had to disable its operation. I wondered if the Iomega was
the cause (the Iomega monitors the D drive, but not the C
drive, for changes and saves the changed files to the USB drive).

I put the old D drive, the seagate 120 GB, back in to D and
reran the test: 43.6 seq read, 43.0 seq write, 4.9 random
seek. I didnt believe it! But..to be sure..I turned the Iomega
back on and rerant the test. I essentially got the same results.

Powered the pc off, turned it back on, iomega was running,
ran the test and got 36 seq read, 35 seq write, 4.7 random
r/w. This is under the same conditions that gave me the bad
results at the beginning. Just for laughs I copied the 388
Mbyte file from disk to disk..took about 20 seconds.

So what happened? The only states that changed was a) the cables
to the drive plugged out and back in (with the maxtor in between)
and b) the bios was set to a different drive and back to the original.

Any thoughts?

It would have been interesting to see what
happened to DMA thru that, bit late now.

I'm betting the cable needed to be reseated.

Yeah, very likely, with retrys producing that obscene thruput.

 

[zigipha]

Sorry, you should be checking that in XP, not the bios.

how do you check thru XP? (thanks in advance).

 

[Peter]

Sorry, you should be checking that in XP, not the bios.

how do you check thru XP? (thanks in advance).

Run | devmgmt.msc
expand "IDE ATA/ATAPI controllers"
"Primary IDE Channel Properties" properties | Advanced Settings
see "Transfer Mode:" and "Current Transfer Mode:" values.

 

[zigipha]

Run | devmgmt.msc
expand "IDE ATA/ATAPI controllers"
"Primary IDE Channel Properties" properties | Advanced Settings
see "Transfer Mode:" and "Current Transfer Mode:" values.

ok got it thanks..

 

[Rod Speed]

(e-mail address removed) wrote

Rod Speed wrote

how do you check thru XP? (thanks in advance).

Propertys of the physical drive in the device manager.

 

[Rod Speed]

(e-mail address removed) wrote

Rod Speed wrote

how do you check thru XP? (thanks in advance).

Propertys of the IDE channel in the device manager.

 

[Rod Speed]

They are indeed, utterly obscene.


Sorry, you should be checking that in XP, not the bios.







It would have been interesting to see what
happened to DMA thru that, bit late now.


Yeah, very likely, with retrys producing that obscene thruput.

Or more likely the cable is flakey and the extra insertions
and removals is what is making the flakeyness come and go.

I'd replace it if it was mine.

 

[Folkert Rienstra]

They are indeed, utterly obscene.


Sorry, you should be checking that in XP, not the bios.







It would have been interesting to see what
happened to DMA thru that, bit late now.


Yeah, very likely,

with retries producing that obscene thruput.

Which the drive would log in S.M.A.R.T.

 

[Rod Speed]

Which the drive would log in S.M.A.R.T.

Thanks for that completely superfluous
proof that you've never had a ****ing clue.

 

[Folkert Rienstra]

I told you your sig goes at the bottom,

--
****wit.

So why is your's here then?

The reason for trying that is to minimize the fragmentation
of that file, instead of defragging the drive.

And that's the shear stupidity of it.
It will occupy the same place it resided in earlier.
Copying it to a different place (by leaving the original where it is)
may get a different result (better or worse).
Defrag is the only way to make sure that the file is contiguous,
whether defragged itself or copied after the defrag.

 

[Rod Speed]

And that's the shear stupidity of it. It will
occupy the same place it resided in earlier.

Wrong. As always. It doesnt with modern OSs, ****wit

Copying it to a different place (by leaving the original
where it is) may get a different result (better or worse).

And someone claimed that captured files tend to be
very fragmented, and that is just plain wrong, and
that is the quick way to prove that the problem aint
fragmentation, when nothing changes with a copy.

Defrag is the only way to make sure that the file is contiguous,
whether defragged itself or copied after the defrag.

Thanks for that completely superfluous proof
that you've never ever had a ****ing clue.

So pig ignorant that you couldnt manage to work
out that you cant get the copy taking THREE
TIMES LONGER due to fragmentation too.