How does data travel from one drive to another on same IDE Channel

[Victor43]

Hello.

I was hoping that someone might know how data travels from one hard drive to another on the same IDE channel or on different channels. Does it go through the Southbridge chipset from one IDE device to the other ? Does it need to go through the Northbridge chipset at all as far as the data goes that is being transfered ? I can see that Windows may need to send data to the AGP card via Northbridge to show the progress of the data transfer but the actual transfer of data goes only through the Southbridge.

Thanks in advance

Victor

 

[greenhawk]

Data goes from the drive, via the cable, to the hdd controller, then over the controllers bus (shared or dedicated depending on the age of the motherboard), then via the chipset (generally the south bridge), then to the northbridge (or cpu depending on the northbridge design) then into the system RAM.

Once enough has been collected (depends on transfer size), then the process is reversed to send data back to the next IDE drive.

the OS sends progress data to the display system as needed.

DMA has allowed larger data blocks and so faster transfers, but the older PIO method was CPU controlled (byte by byte).

Of course, if you want answers for homework, best google it as while the process is similar, the process has changed slightly over the years (ie: which devices do which work).

 

[Victor43]

Data goes from the drive, via the cable, to the hdd controller, then over the controllers bus (shared or dedicated depending on the age of the motherboard), then via the chipset (generally the south bridge), then to the northbridge (or cpu depending on the northbridge design) then into the system RAM.

Once enough has been collected (depends on transfer size), then the process is reversed to send data back to the next IDE drive.

the OS sends progress data to the display system as needed.

DMA has allowed larger data blocks and so faster transfers, but the older PIO method was CPU controlled (byte by byte).

Of course, if you want answers for homework, best google it as while the process is similar, the process has changed slightly over the years (ie: which devices do which work).

Thanks GreenHawk for the answer. This question is actually not for homework but to determine the source of my issue. You see when I perform a restore of an hard disk image from a DVD (used Norton Ghost) back to the same hard drive the speed of the transfer has decreased from what it used to be. As a result it used to take about 30-40 minutes for the cloning (DVD to disk) to complete but now it takes well over an hour and a half. The same amount of data since its on the same DVD and the same hard drive. No other change was made to the system like reducing the RAM or changing the CPU speed or cables or any tweaking or changing of the BIOS settings.

Can the Northbridge or Southbridge chips or buses control the transfer speed of the path the data that is being sent from the DVD to the hard drive ? Even if I change the two devices to different channels is does not make any difference. What about the memory controller that is built into the Northbridge chip can this cause a slow down ? I'm more interested in finding out if either the NB or SB chipset could cause or control the slow transfer speed ?

Thanks again for the reply.

Victor

 

[yottabit]

IIRC, IDE assumes the transfer rate speed of the slowest drive that is on the same channel, so you never want to put your DVD drive on the same channel as your hard disk, and you wouldn't want to group an 133 disk with a 66 disk for example

If you have a second header on your motherboard use that and a seperate cable for your DVD drive!

Check the transfer rate that is being detected in the BIOS and it may be a good idea to check the SMART information if your drive is capable

 

[greenhawk]

What about the memory controller that is built into the Northbridge chip can this cause a slow down ?

no. The speed of memory is many times faster than a HDD, let alone a optical drive.

My money would be on the dvd disk or dvd drive. Thirdly on the HDD dieing, but that is a long shot.

I say the dvd disk is most likly as burnt disks do degrade over time and so have issues running at full speed. A iffy dvd drive can also cause some slow downs due to a dirty read lens, but that is less common than a dvd disk degrading (espically a burnt disk).

 

[Ketchup]

From what I am reading, a failing hard drive could very well be the culprit. Assuming that there have been zero changes to the drive setup and the bios settings, this would likely be the cause, as it is the second-slowest part of this process (your DVD drive being the slowest.) When visiting my parents last year, I noticed their computer had slowed down quite a bit. After investigating other possible causes, Seatools indicated the drive needed to be replaced. Cloning the contents of the drive onto a new one gave a dramatic improvement.

Another idea would be to check the DVD for scratches, which would cause a slower read from the drive.

 

[piasabird]

Probably the software is creating the image on the hard drive and then burning the image on the DVD all at once. If these are large images, then you are moving a lot of data around on the hard drives. This can cause fragmentation on a hard drive. Over time hard drives can become fragmented. What happens is bits of data files become located all over the hard drive and it takes longer to find them. So if you defrag the hard drive this may speed up the process. After defrag process parts of files are placed closer together and it takes less time to find them. This may help a little bit. If you have a really large drive it may need to run overnight or for a few hours. Also over time drives themselves get bad spots on the drive. If the drive goes bad sometime some damage occurs on the surface of platters. I think through the defrag process that the bad sectors are marked and avoided in the future.

This is why I do not like to keep using old drives accross several builds. The data on the drives is important so periodically buy new hard drives as you buy new motherboards. It is a major pain to have to take a computer apart just to replace a failing hard drive.

I concur with using DMA to speed up the transfer process. Sometime it is not turned on in the BIOS. Having matched RAM of equal specifications can also speed this up. Having a good power supply with a steady supply of power can help both the hard drives and the memory. Fluctuations can cause data corruption on the drives and in the RAM.

 

[velis]

Greenhawk's explanations have been exact though lacking in one single point of the original question:
1. If you have two devices on the same PATA cable, the controller will synchronize the entire channel to the slowest transfer speed of both devices (not actual transfer as yottabit seems to suggest). if your setup isn't REALLY old as in 486 era computer, you should have both devices at least on ATA 66 if not 133, both also in DMA mode. I'm not sure what happens if one device is DMA capable, but the other is PIO, but this can't really play much part in restoring since the operation isn't exactly allowing you to play Crysis while waiting. The CPU should handle PIO just fine.
2. When dealing with two devices on one cable, only one of them can be transferring data at a time. This is determined by one of the pins in the cable. When it's on, the master works, when not, slave does. This does show significantly when transferring from one device to the other because you effectively halve your available bandwidth.
3. So having each device on a separate cable reduces both issues since the controller synchronizes to max speed of the device and doesn't have to share transfer time.

You never said if you modified the setup from two cables to a single one. If you did, this could be your culprit. Otherwise I would tend to agree with greenhawk.

There is one more option though: you may have modified ATA parameters in bios. Older BIOSes allowed to select data word sizes (8 / 16 bits), max DMA speed or max sync protocol (PIO1..5, DMA33 / 133). If you by chance modified any of these and reduced them to a lower value, this may also play part in your woes.