Reason for different IDE performances between 2 internal drives?

  • Thread starter Thread starter zigipha
  • Start date Start date
Z

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
 
(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
Click to expand...
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
Click to expand...
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.
Click to expand...
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.
Click to expand...

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

Check that DMA is enabled on the Seagate.
 
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.
Click to expand...
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.
 
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.
Click to expand...

Fragmentation shouldnt triple the copy time.
 
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?
 
(e-mail address removed) wrote
I thought it might be frag, but it wasnt convienient to defrag,
Click to expand...

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.
Click to expand...

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.
Click to expand...

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?
Click to expand...

Yes, that is certainly a myth.
 
Rod Speed said:
(e-mail address removed) wrote


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

Clueless, as always.
I'd be amazed if it was that with the Seagate being 3 times slower.
Click to expand...

Of course you would. Layers of egg to be washed off of your face.
 
Clueless, as always.
Click to expand...

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.
Click to expand...

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

Have fun explaining why only that drive is severely fragmented.
 
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.
Click to expand...

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
 
(e-mail address removed) wrote:
Click to expand...
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.
Click to expand...
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...
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).
Click to expand...
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.
Click to expand...
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.
Click to expand...
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.
Click to expand...
Any thoughts?
Click to expand...

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.
Click to expand...

Yeah, very likely, with retrys producing that obscene thruput.
 
Sorry, you should be checking that in XP, not the bios.
how do you check thru XP? (thanks in advance).
Click to expand...

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

ok got it thanks..
 
Rod Speed said:
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.
Click to expand...

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.
 
Rod Speed said:
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,
Click to expand...
with retries producing that obscene thruput.
Click to expand...

Which the drive would log in S.M.A.R.T.
 
Rod Speed said:
I told you your sig goes at the bottom,
Click to expand...

--
****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.
Click to expand...

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.
 
And that's the shear stupidity of it. It will
occupy the same place it resided in earlier.
Click to expand...

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).
Click to expand...

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.
Click to expand...

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.
 
Back
Top