2nd HDD

  • Thread starter Thread starter FeeNix
  • Start date Start date
F

FeeNix

Hi

I was just wondering wether anyone can forsee any problems with throwing my
old hard drive into my new system? you see my old system died (long story
but wont boot, tried few things from researching theNG's but no joy) and cos
it was pre CD-RW there is a lot of stuff on there that I would like to
recover. So my new system can take a 2nd drive but just wanted to check cos
I'm now running winXP and old drive has win98 installed on it. Shouldn't be
a problem tho as long as I change the jumpers to Cable select. Right?

Any comments well appriciated.

Nik
 
Hi

I was just wondering wether anyone can forsee any problems with throwing my
old hard drive into my new system? you see my old system died (long story
but wont boot, tried few things from researching theNG's but no joy) and cos
it was pre CD-RW there is a lot of stuff on there that I would like to
recover. So my new system can take a 2nd drive but just wanted to check cos
I'm now running winXP and old drive has win98 installed on it. Shouldn't be
a problem tho as long as I change the jumpers to Cable select. Right?

Any comments well appriciated.

Nik

You shouldn't have a problem but if your present drive is set to
Master just set the old drive to Slave and put it on the same cable or
on the 2nd IDE port.



--
Free Windows/PC help,
http://www.geocities.com/sheppola/trouble.html
email shepATpartyheld.de
Free songs download,
http://www.soundclick.com/bands/8/nomessiahsmusic.htm
 
Shep© said:
You shouldn't have a problem but if your present drive is set to
Master just set the old drive to Slave and put it on the same cable or
on the 2nd IDE port.


If the old drive is put on the other IDE channel, and it's the only
device on that channel, it doesn't matter whether it's Master or Slave.
The important thing is that the "real" OS is on the drive that has highest
priority in the BIOS boot sequence so that the BIOS looks for it there
first.

*TimDaniels*
 
I believe that if the HD your putting in has an 'active' partition it would make a difference. the boot sequence would look for the
first active partition, so put it as the slave on the primary would be my suggestion.
 
If put your old HD to first IDE channel as slave, it should be fine, your
old OS files will just be treated as data. If put your old HD to second IDE
channel as master/single/slave, you will be fine too.

The old HD will never be assigned as C: and if your BIO boot sequence
setting is A,C as people normally do, I don't see any problem, and I have
done this before.

For safety reason, surely, after you moved/copied all the data on the old
HD, you better erase all OS files on it. If I were you, I fdisk and format
it to get rid of all the system and boot related files, just to make sure
it is a storage disk.
 
FeeNix said:
Hi

I was just wondering wether anyone can forsee any problems with throwing my
old hard drive into my new system? you see my old system died (long story
but wont boot, tried few things from researching theNG's but no joy) and cos
it was pre CD-RW there is a lot of stuff on there that I would like to
recover. So my new system can take a 2nd drive but just wanted to check cos
I'm now running winXP and old drive has win98 installed on it. Shouldn't be
a problem tho as long as I change the jumpers to Cable select. Right?

Any comments well appriciated.

Nik

Not sure about XP, but I put an old Win98SE drive into a 2000 Pro machine as
a data drive (if possible - make it slave and put it on same ribbon as boot
disk, as someone suggested) and everytime it booted I got some message about
scanning the old HD because of inconsistant formats (2000 prefers NTFS while
the 98 was FAT32) and I had to press the space bar to cancel the scan or the
drive may not be visible once Windows started. As I said, I have no idea if
XP does it also but I know XP also prefers NTFS. So, once you're in, save
everything you want off the old HD and then reformat it NTFS.
 
Not sure about XP, but I put an old Win98SE drive into a 2000 Pro machine as
a data drive (if possible - make it slave and put it on same ribbon as boot
disk, as someone suggested) and everytime it booted I got some message about
scanning the old HD because of inconsistant formats (2000 prefers NTFS while
the 98 was FAT32) and I had to press the space bar to cancel the scan or the
drive may not be visible once Windows started. As I said, I have no idea if
XP does it also but I know XP also prefers NTFS. So, once you're in, save
everything you want off the old HD and then reformat it NTFS.


XP doesn't 'prefer' NTFS or FAT32, it'll work fine from either. If OP
wants NTFS that's fine but it has absolutely nothing to do with having
a 2nd drive. Actually it would be better to have the 2nd drive as
FAT32 because it has legacy support.


Dave
 
Actually it would be better to have the 2nd drive as FAT32 because it has
legacy support.

And also if the OP became a *nix user and wanted guaranteed access to his
data on this drive its especially wise to format it as FAT*, since *nix
properly supports FAT* but not NTFS.
 
Cable select is rarely used on hard drives, you should set it is slave if it is on the same cable as another drive.
If you place two drives on the same cable the port will operate at the highest speed that both drives support. This could make the drives slow. If the faster drive supports DMA 4 and DMA 5, and the slower drive supports only DMA 1 and DMA 2 then both drives will run in very slow PIO mode.
 
Cable select is rarely used on hard drives, you should set it is slave if it is on the same cable as another drive.
If you place two drives on the same cable the port will operate at the highest speed that both drives support. This could make the drives slow. If the faster drive supports DMA 4 and DMA 5, and the slower drive supports only DMA 1 and DMA 2 then both drives will run in very slow PIO mode.
Used to be this way before modern IDE controllers with dual-fifo. Now, IDE
runs with independant timing for each drive. Been this way since the TX
chipset.

JT
 
Cable select is rarely used on hard drives, you should set it is slave if it is on the same cable as another drive.
If you place two drives on the same cable the port will operate at the highest speed that both drives support. This could make the drives slow. If the faster drive supports DMA 4 and DMA 5, and the slower drive supports only DMA 1 and DMA 2 then both drives will run in very slow PIO mode.

You'd be surprised how often it IS used. Many drives ship jumpered as
CS, because the manufacturer knows it works.


Dave
 
Used to be this way before modern IDE controllers with dual-fifo. Now, IDE
runs with independant timing for each drive. Been this way since the TX
chipset.

JT

Both the above statements are incorrect.
Having two drives of differing speeds on the same IDE port only affect
performance if both drives are accessed at the same time.
Nothing has changed since any chip set.If you wish to test this(as I
have many times) do an,"On-the-fly" disk to disk burn with Two
CDrom/CDR/W drives on the same IDE port and then with each in separate
IDE ports.You will find it's near twice as fast if they are on
separate IDE ports.
Also
I have a 133 Maxtor running at full speed with a standard Cdrom drive
on the same IDE port.The data transfers from the hard drive are not
affected by the Standard CDRom drive unless it's accessed whilst there
are data transfers from the hard drive e.g the Cdrom drive is
invisible to the hard drive until accessed.
HTH :)





--
Free Windows/PC help,
http://www.geocities.com/sheppola/trouble.html
email shepATpartyheld.de
Free songs download,
http://www.soundclick.com/bands/8/nomessiahsmusic.htm
 
Both the above statements are incorrect.
Having two drives of differing speeds on the same IDE port only affect
performance if both drives are accessed at the same time.
Nothing has changed since any chip set.If you wish to test this(as I
have many times) do an,"On-the-fly" disk to disk burn with Two
CDrom/CDR/W drives on the same IDE port and then with each in separate
IDE ports.You will find it's near twice as fast if they are on
separate IDE ports.
Also
I have a 133 Maxtor running at full speed with a standard Cdrom drive
on the same IDE port.The data transfers from the hard drive are not
affected by the Standard CDRom drive unless it's accessed whilst there
are data transfers from the hard drive e.g the Cdrom drive is
invisible to the hard drive until accessed.
HTH :)


The statements are correct. Your second paragraph somewhat confirms that
there is independant timing of ide devices on current ide controllers,
which is what I said. If the 2 cd devices are new enough to do DMA
transfers, then I have found the performance is fine on the same cable. PIO
mode slows down transfers, and eliminates any advantages of independant
timing.

Prior to the TX chipset on Intel, and on earlier chipsets from other
manufacturers, there was only a single FIFO buffer for both drives, and the
timing was limited by the slowest drive on the channel. That changed when
dual FIFO was introduced. Then it was possible to run each drive at maximum
speed on the channel. Using both drives at the same time can slow the
transfer down. This does not contradict what I said. The slow down is from
congestion on the channel, poor drivers, PIO mode devices, etc..

JT
 
The statements are correct. Your second paragraph somewhat confirms that
there is independant timing of ide devices on current ide controllers,
which is what I said. If the 2 cd devices are new enough to do DMA
transfers, then I have found the performance is fine on the same cable. PIO
mode slows down transfers, and eliminates any advantages of independant
timing.

Prior to the TX chipset on Intel, and on earlier chipsets from other
manufacturers, there was only a single FIFO buffer for both drives, and the
timing was limited by the slowest drive on the channel. That changed when
dual FIFO was introduced. Then it was possible to run each drive at maximum
speed on the channel. Using both drives at the same time can slow the
transfer down. This does not contradict what I said. The slow down is from
congestion on the channel, poor drivers, PIO mode devices, etc..

JT

I disagree.
The relationship on IDE ports is a Parent and two child devices.The
Parent Device e.g only one device on the port can multi task e.g read
and write at the same time however if there are two devices on the
channel they both become,"Children" and have,"Wait states" if both are
accessed at the same time and this is even if both devices are UDMA6.
Try a large file copy from two identical drives on the same IDE port
and then try it from two hard drives on separate ports and you will
see the speed difference as with two Cdrom drives on the Same IDE
port.
I've bench tested all configurations and then chosen the best for my
usage.
HTH :)




--
Free Windows/PC help,
http://www.geocities.com/sheppola/trouble.html
email shepATpartyheld.de
Free songs download,
http://www.soundclick.com/bands/8/nomessiahsmusic.htm
 
I disagree.
The relationship on IDE ports is a Parent and two child devices.The
Parent Device e.g only one device on the port can multi task e.g read
and write at the same time however if there are two devices on the
channel they both become,"Children" and have,"Wait states" if both are
accessed at the same time and this is even if both devices are UDMA6.
Try a large file copy from two identical drives on the same IDE port
and then try it from two hard drives on separate ports and you will
see the speed difference as with two Cdrom drives on the Same IDE
port.
I've bench tested all configurations and then chosen the best for my
usage.
HTH :)


Still doesn't address what I said, or what the original poster said. If you
have 2 devices on a channel, 1 that is UDMA4, and one that is UDMA 6, they
will run at the UDMA speed they are capable of on a modern chipset. The
data transfer from the drive for that transfer will be at UDMA 4 or 6,
regardless of what the other drive is. That was the point. When you have 2
IDE drives on a channel, performance can be affected by other things, but
they drives are running at their max speed when they transfer data.

So what causes the slow downs you observe? In some cases it is poor
drivers. Some times it is controllers that require a lot of CPU time, even
with DMA. Sometime it is poor interupt routines, because all drives on a
channel share an interupt. In most cases, it is definitely best to have
drives like CD Roms and CD Burners on seperate channels, but that still
doesn't invalidate what I said.

JT
 
Still doesn't address what I said, or what the original poster said. If you
have 2 devices on a channel, 1 that is UDMA4, and one that is UDMA 6, they
will run at the UDMA speed they are capable of on a modern chipset.
But not if accessed at the same time.
The
data transfer from the drive for that transfer will be at UDMA 4 or 6,
regardless of what the other drive is.That was the point.
Only if the other device is not being accessed.
When you have 2
IDE drives on a channel, performance can be affected by other things, but
they drives are running at their max speed when they transfer data.
Only correct if the above is true.
So what causes the slow downs you observe? In some cases it is poor
drivers.
Not against the inherent nature of the Parent/Child relationship
Some times it is controllers that require a lot of CPU time, even
with DMA
Not against the inherent nature of the Parent/Child relationship
Sometime it is poor interupt routines, because all drives on a
channel share an interupt.
Not against the inherent nature of the Parent/Child relationship
In most cases, it is definitely best to have
drives like CD Roms and CD Burners on seperate channels, but that still
doesn't invalidate what I said.

By separate channels do you mean on separate IDE ports or separate
from the hard drives?
The data slow downs I have explained above.It's the inherent nature of
the Parent/Child relationship of IDE ports and the Child devices not
being able to multi-task.Nothing to do with drivers or IRQs etc but of
course these could add to or cause problems if incorrectly setup.
You can test this as I have quite easily many times :)





--
Free Windows/PC help,
http://www.geocities.com/sheppola/trouble.html
email shepATpartyheld.de
Free songs download,
http://www.soundclick.com/bands/8/nomessiahsmusic.htm
 
But not if accessed at the same time.
Inaccurate. IDE doesn't support concurrent operation like SCSI so there is
no "access at the same time". (at least not yet).
Only if the other device is not being accessed.
No concurrent operation so meaningless. When a device is transfering data,
it is always at the max rate, because only one device is active at a time
on an IDE channel.
Only correct if the above is true.
Which it is because when a device is transfering data on an IDE channel, it
is the only device transfering data on the channel. No concurrent
operation.
Not against the inherent nature of the Parent/Child relationship
Parent/child has nothing to do with it.
Not against the inherent nature of the Parent/Child relationship again, does not apply.

Not against the inherent nature of the Parent/Child relationship again does not apply.

By separate channels do you mean on separate IDE ports or separate
from the hard drives?
Each ide channel is a separate port.
The data slow downs I have explained above.It's the inherent nature of
the Parent/Child relationship of IDE ports and the Child devices not
being able to multi-task.Nothing to do with drivers or IRQs etc but of
course these could add to or cause problems if incorrectly setup.
You can test this as I have quite easily many times :)
The lack of support for concurrent operations makes multitasking difficult.
There is not "simultaneous" operation on IDE. One command outstanding per
channel/port. Add poor drivers that don't bother with the limitations due
to this lack, and you get poorer performance than necessary. Your tests are
not testing the transfer from the drive alone, but the whole process of
transfering the information from one drive to another. The slow downs are
there, but not because the drive is transfering at a lower speed when it is
transfering data.
 
Back
Top