RE: install sloooow doooown

Ernie,

I am always impressed with the great stuff I continue to learn by
monitoring these forums.

Thanks for adding to my limited knowledge.

stew


[email protected] wrote:
> 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


---
Outgoing SofTEC USA mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003