RE: install sloooow doooown

"Kenneth Goodwin" <[email protected]>
Newsgroups gmane.linux.redhat.release.enigma
Message-ID <ACC36DFE0F2E0948993CC7858D6B60EB154938@DMTECHMAIL>
see below

++> Well, in my limited knowledge let me pass on what I have
++> learned.  I come
++> from the ole SCSI UNIX days where we would NEVER put an IDE
++> drive into a UNIX
++> system.  They all had to be SCSI no matter how much it
++> costed.  The reason at
++> the time (might not still be valid but I think it is) was
++> that when the
++> system made a disk request to a SCSI device it could
++> disconnect from the
++> device and let the device handle the request and when the
++> request was done it
++> would then interrupt the cpu to tell it that the request
++> was done.  IN THE
++> MEAN TIME, being a UNIX, multitasking machine, the cpu was
++> able to handle a
++> multitude of actions in the milli seconds the SCSI
++> controller handled the
++> request.

I am apparently even older than you, I come from PERTEC controller days.
Ouch!
Some things are redundant to Stew's statements, memory may be vague since my
IO driver writing days in UNIX V6/V7
but:

Several reasons for SCSI earlier on  -
	The main reason for using SCSI in servers - Like Pertec -
		Seven drives per disk chain as opposed to IDE's two.
		(now up to 15 drives on Wide scsi.)

	better performance than Pertec controllers, became cheaper as well in time.
	Controller supported DMA IO to RAM.
	SCSI controllers were faster IO bus wise than IDE.
	DMA meant that One drive could be transferring while all the others could
be set to seek to the next CTS
	to be read/written by the controller. I think the seek operations need to
be started first
		but the controller can take the seek completion interrrupt nwhile the dma
continued
	DMA also freed the cpu to do other things while the disk controller handled
the data transfer.
		the cpu was only needed to handle the device interrupts and schedule the
next tasks on the 			controller.

However that advantage has been mostly dead for some time now.
	EIDE/UDMA provides
		The same two drive limitation as older IDE, yuch!.
		Transfer rates comparable to all versions of SCSI at a lower cost.
			(one standard is always ahead for a short time until the other catches
up.
		Lower cost than SCSI across the board.
		DMA IO with all the advantages.
		I am not sure if parallel seek is available.
		I am not sure if the Controller has to stay locked to the drive anymore
since the DMA operation
		is usually handled by a separate chipset. I dont think a parallel seek can
be done while the IO
		operation is in progress since that requires a switch on the master-slave
unit select control line.
		I think the driver would have to start all the seeks in motion and start
the DMA Io on the
		first drive to reach the correct position.

I think the real main difference today is that SCSI can handle far more disk
drives per server than an
EIDE based system.

My General Rule -
	if you are building a low end server or workstation without huge disk drive
needs or IO demands
		use UltraDMA/133 or slower EIDE controllers and 200 GB or smaller EIDE
harddrives.

	if you need a server with more disk capacity, use high end Ultra Scsi disk
controllers
	and large capacity scsi disk drives	(Ultra 160's may be the fastest at this
point if memory serves
	correct.

	And if you want really fast disk performance and have oodles of cash -
FibreChannel 2 at 2 Gbps
	using dual Fibrechannel switches and dynamic Multipathing for redundancy -
use arrays of Fibrechannel
	drives with hardware raid controllers in the array.


  >> WHERE-AS with IDE, the cpu is NOT able to
++> disconnect from the
++> controller after the request is put out to the controller
++> until an answer is
++> provided from the controller.  That is my understanding.
++> Read on for info on
++> 2 IDE drives on the same controller.
++>
++> So you might say, so what, we are talking about milli
++> seconds here, well, yes
++> we are but we are also talking not about a system sitting
++> in front of a
++> single individual waiting for him to finish his next sip of
++> coffee but a
++> machine that might be a web server, mail server,
++> authentication server, dhcp
++> server, and a hundred other types of servers.  Milli
++> seconds count big time
++> here.
++>
++> Anyway, why not 2 drives on a single IDE chain.  Well, all
++> the info I have
++> read about RAID (and ALL of my servers implement some level
++> of RAID) say DO
++> NOT put 2 drives on a single IDE chain.  Therefor I don't.

I think this only applies if you plan to RAID those two drives together
say in a RAID 1 mirror. That chokes the IDE BUS down doing double IO's to
those drives
If you do RAID, you mirror Drive 0 on IDE chain 0 to Drive 0 on IDE chain 1.
If you dump the cdrom drive, mirror drive 1 to drive 1 as above.
You can have three hard drives and a cdrom on your IDE chains as long as
only the two
master IDE drives are involved in a RAID 1 drive to drive mirror. Raid 5 is
totally out of the question.

In  any case, you would be better off with a hardware RAID controller with
onboard cache.

The same chain to chain Raid 1 mirror rule applies to SCSI buses for the
same reason.
RAID 5 is possible. striping is possible with SCCI because of the higher
drive numbers and
the paraller seek capability.

++>
++> One additional note, ALL of my servers use SCSI drives in a RAID
++> configuration for their main system drives.  I use IDE
++> drives in a RAID
++> configuration for the users data storage drives and as
++> backup for remote
++> systems.  Why??  Well, IDE drives are BIG (GB) & DIRT
++> CHEAP!!!! and I don't
++> need big drives for the system, just for the users data.

I agree..........


++>
++> Hey, I might be wrong in my explanation.  Please chime in
++> if you have more
++> technical info to add.
++>
++> Thanks.
++>
++> stew
++>
++>
++>
++>
++> >
++> > --
++> > Regards, Ernie
++> > 100% Microsoft and Intel free
++> >
++> > _______________________________________________
++> > enigma-list mailing list
++> > [email protected]
++> > https://listman.redhat.com/mailman/listinfo/enigma-list
++>
++>
++>
++> >>
++> >> Stewart M. Ives
++> >> SofTEC USA
++> >> 1717 Bridge St
++> >> New Cumberland, PA 17070
++> >>
++> >> Tel: 717-774-4233
++> >> Fax: 717-774-1808
++> >> EMail: [email protected]
++> >> WebSite: www.softecusa.com
++> >>
++>
++>
++>
++> _______________________________________________
++> enigma-list mailing list
++> [email protected]
++> https://listman.redhat.com/mailman/listinfo/enigma-list
++>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.