Hard Drive bottlenecking?

[tahlsr]

So my brother built a system wanting to put all drives on seperate buses to alleviate any data transfer bottlenecks. He is on a abit nf7-s board with a barton 2500+ and 1 gig of corsair xms ram.

So his boot drive is a seagate 18gb 15k.3 on a LSIU-160 SCSI Card.
He has a 200gb WD2000JB on a pci card (the one that came with the WD)
and a pci serial ata raid card that he connected 2x120gb (wd1200bb) drives to.
he has a dvd player on ide 1 and a burner on ide 2. He has every drive set to master. So......

He transfers a large file from the 200 giger to the 2x120 raid array and his mouse and system get choppy. (oh yeah this is on winxp with all updated everything). His cpu is at 20% so why why why would there be choppines.

I don't know much about pci slots and if they share bandwith and I think they go to the Southbridge so should he maybe screw his 200 giger on the pci card and put that in one of the ide slots on the mobo?

Thanks for any info people can provide on this scenario and in general about pci slots and if they share bandwith and if it's 133MB/s and stuff like that. So my guess is that the pci bus is getting bottlenecked and so the boot drive which is in a pci slot can't do it's thing and so the system seems choppy. Is that right?

 

[Teq]

Sounds like he's got it set up so well he's saturating the PCI buss. An SCSI drive running files into a RAID array can manage transfer speeds so high that it could saturate the PCI buss which will bog the system.




---><font color=green>It ain't better if it don't work</font color=green><---

 

[tahlsr]

It sounds like you are implying that the pci bus is shared by all pci slots. If this is the case, does that mean then that there is about 133MB/s to saturate? Also, are the ide channels completely seperate bus pathways? If so that would mean that putting one of the 'most used' hard drives on the ide channel could prove helpful here.

 

[unoc]

The PCI bandwidth is 133 MB/s. That's all and for all the devices. To have higher bandwitdh you can go with PCI 64 bit/66 MHz bus which accompains most chipset dedicated to dual processor boards.
In these cases you may use up to 266 MB/s.
Unfortunately these boards are expensive as well as multiprocessing CPUs (XEON and Athlon MP).


______________________
<font color=red>you don't need a faster computer, you need faster fingers for your hand</font color=red>

 

[tahlsr]

thanks for the reply, I guess all that is left to do is to move one drive to one of the ide channels and see if that resolves the issue.

 

[gaviota]

I have a very similar setup, with the exception that in my case I have only the SCSI hard disk running from a PCI card, while my striped array is running on an onboard Promise controller, and my individual hard disks, CD-RW and DVD are running from the IDE ports.
I dont have the problem you described, so I think the problem is definitely because in your case the PCI bus is a bottleneck.


__________________________________________________
It's not important to know all the answers, as long as you know how to contact someone who does.

 

[Guest]

The onboard IDE controllers are also on the PCI bus. By moving the drives there all you are doing is changing controllers, but it could still help/hurt.

Years ago I noticed what you are seeing. I upgraded to all SCSI hard drives and the problem was gone.

 

[Teq]

The IDE controller is simply a device installed on the PCI buss... you'd get the same saturation problem using it.

One of the reasons IDE only supports 4 devices --one at a time-- is to prevent buss saturation on busy machines.


---><font color=green>It ain't better if it don't work</font color=green><---

 

[unoc]

To speed up data transfer and operation of your PC you can provide to install the devices which may work simultaneously on different channel. In fact on each IDE channel (even on standard IDE interface or IDE controller on PCI bus) you can read OR write and NOT read AND write simultaneously. As example you should install the OS on a different drive/channel than the page file (virtual memory) so allowing to read from the OS file while writing on the page file. The same for application. Theorically you should have three different channel for application, OS and page file. The same applies for CD ROM and CD burner.
If the two CD devices are installed on the same channel, you will have problems to perform copies "on the fly" because it is not possible to read from the CD ROM while writing on the CD burner.
This applies only for IDE channels.

______________________
<font color=red>you don't need a faster computer, you need faster fingers for your hand</font color=red>

 

[tahlsr]

using the onboard serial controller would be seperate from the ide and pci bus, right? It's a Abit nf7-s mobo with a silicon technologies serial ata raid controller. Would that help divert the bottleneck?

 

[Guest]

No, IDE and Serial ATA controllers are both on the pci bus as well. Your PCI bus bottleneck is still present.

The only way around that is transfering the data across a different, and better bus, thus my previous SCSI recomendation. There are other solutions that could work also.

 

[Teq]

Ummm... an SCSI controller <i>Still</i> plugs into the PCI buss.

The only way around this is to use the standard master/slave setups and let the IDE controllers handle the bandwidth issue. There is no way you are going to get half a dozen ATA100 (or better) drives all running at once without exceeding the PCI bandwidth. The controllers account for this by only allowing one operation on each channel... eg. read from primary master, write to secondary slave... thus there are never more than two IDE data streams using the PCI buss at the same time. By using 4 separate controllers you defeat that consideration.




---><font color=green>It ain't better if it don't work</font color=green><---

 

[Guest]

Ummmm.... that may be true, but since the poster is talking about drive to drive transfers, there is no reason for the DATA to go to the PCI bus. Data tranfers between drives on the same card can be whatever that bus allows with no restrictions from the PCI bus.

I meant to say that, but I don't know if you can actually buy a controller that does SCSI RAID and regular single drive SCSI all at the same time.

 

[Teq]

Ummm no... <i>Everything</i> in a PC goes through the CPU...

Believe me... nothing happens without the cpu intimately involved. Even between two drives on the same controller the data is still read from the platter, through the cables, through the card, through the pci buss, through the south bridge, through the north bridge into CPU registers then into memory... and then back out by a reverse path to the other drive.

Now, in a multitasking environment with multiple controllers this means that you can launch multiple simultaneous and unrelated file copies... you can have stuff flowing from C to D, E to F, F to c, etc. all at once. Without the coordination of a central controller, the PCI buss just can't sustain this and keep everything going full speed... so even with very low CPU usage, you can still have a system bottleneck.


---><font color=green>It ain't better if it don't work</font color=green><---

 

[Guest]

Well teq, with all due respect, that is wrong.

Ultra160 SCSI is an example, it has a SCSI bus bandwidth of 160MB/sec. Devices on the same SCSI bus may transfer data at a maximum rate of 160MB/sec.

In reality SCSI controller/drives in a WinXP environment need relatively little input from the host CPU to finish a task, once a command has been recieved.

You can read a site that agrees here (near the bottom):
http://scsi.radified.com/scsi_03a.htm

Poke around that site a while they have quite a bit. I know it's not proof, but look around elsewhere and you will find that the rest of the world is in agreement with me about these things too.

 

[Teq]

You have to realize what level this guy is talking about when he says "the data being transferred"... he's not talking about files, or even allocation units... he's talking about SECTORS. In a buffered controller you can move a sector from disk to disk without putting it into main memory... The drives themselves and their controllers are not aware of file systems, directories, file sizes or the location of the files on a drive. The software (i.e. OS and application) still have to read <i>at least</i> the directory and file parameters into memory to direct those disk activities on a sector by sector basis.

File move and copy operations still take place very much as I described. This is simply because the drives operate only at the lowest level, even on an SCSI drive. All the smarts (files, allocation units, directories etc.) still reside with the OS which is software which is run on a CPU who's only access to the information is through that PCI buss.






---><font color=green>It ain't better if it don't work</font color=green><---

 

[lhgpoobaa]

Acutally unoc ive had no issues with two drives on the same channel copying on the fly... and these are fast 48x units, burning at 48x too. (both ata-33 on a 80wire cable)

<b>Melb_angel = THGC's <i>INNOCENT</i> Angel</b>
<A HREF="http://www.picturetrail.com/master_poobaa" target="_new">PooBaa's Pics!</A>

 

[unoc]

If you may copy files between two devices on the same channel you have to thank the buffer of the burner which deliver data to burn while the bus transfers data read from the CD. But you may have problems for certain big files. This is not a my opinion, but it is the recommendation of all cd burner software as soon as you starts an "on the fly" copy.
The fact that on the same channel you cannot read and write simultaneously, is a well known bottleneck of ide channels. This problems let you understand how "phisically problematic" is for the system to sustain a read-write operation at the same time on the same channel only with the aid of the burner-buffer which feeds the burner with data as soon as they are not available (because the system read from the cd and cannot write to the buffer).
Sometimes may be convenient to have all the optical devices on the same channel. This only may cause the need to use the hard disk as "buffer" for the cd copy renouncing to burn on the fly but avoiding to slowdown the UATA 100/133 hard disk connecting them on the same channel of the optical devices.
The ata-33 standard does not need the 80 wire cable so you can use a more reliable 40 wire cable for the CD and for the burner.


______________________
<font color=red>the new bios of my mobo let me to choose the P.rating number of my CPU.
Now I have an XP 8000 + </font color=red>

 

[lhgpoobaa]

i have done some experimenting on this, using 48x reads and 48x burns using nero...
and i can get uninterrupted burns with the ultrabuffer size down to 16mb or less. (max is 80). The ultra buffer is the memory buffer using system ram IIRC.

and i dont have any rounded 40 wire cables. aso i use 80 ones with no issue. moot point.



<b>Melb_angel = THGC's <i>INNOCENT</i> Angel</b>
<A HREF="http://www.picturetrail.com/master_poobaa" target="_new">PooBaa's Pics!</A>

 

[Guest]

"The drives themselves and their controllers are not aware of file systems, directories, file sizes or the location of the files on a drive.....All the smarts (files, allocation units, directories etc.) still reside with the OS which is software which is run on a CPU who's only access to the information is through that PCI buss."

Agreed, but I would add some things. All that bookeping librarian stuff your talking about will consume very little data space with respect to actual file sizes. It's only logical that the difference between a files coordinates, and its contents would be larger as file size went up and disk file fragmentation went down.

Huge files (mp3's, avi's, exe's, etc.) could be being swapped on an ultra160 SCSI bus between up to 15 high speed drives simultaneously, while the only information which needs to go back and forth between the CPU and controller via PCI bus is this adressing data you mention. There is no reason for the actual file data to go to the CPU for inspection or anything since we're just moving it not trying to operate upon it. The PCI bus will be barely used for several big files being transferred between several fast drives on the same bus.