Jihad needs scientists
in [Design]
|
From: MassiveProng on 6 Mar 2007 20:06 On Tue, 6 Mar 2007 10:09:04 -0500, krw <krw(a)att.bizzzz> Gave us: >> I believe it sits on the IDE I/O channel, and accepts (through a >> driver) some standard subset of I/O commands, which are now supported >> in hardware at/on the IDE I/O chip. >> >Can you say ATAPI, MassivelyWrong? It STILL is NOT a hard drive controller, dumbfuck. For that bus, they reside ON THE DRIVE.
From: MassiveProng on 6 Mar 2007 20:11 On Tue, 6 Mar 2007 10:11:14 -0500, krw <krw(a)att.bizzzz> Gave us: >Sorry, that's what they're called. ...perhaps just to keep >MassivelyWrong confused. No they are not. They are BUS controllers. When and if a hard drive is placed on the bus, they also are the controller for it/them. Dedicated SCSI hard drive controllers are specifically designed for RAID applications, and usually do not accept other types of SCSI devices, only hard drives. THAT is a hard drive controller. Google Adaptec SCSI Bus Controller, and Google Adaptec SCSI Hard Drive Controller, and you get two completely different lists of products. 600k hits for one and 800k hits for the other. Try again.
From: MassiveProng on 6 Mar 2007 20:14 On Tue, 06 Mar 2007 17:49:59 +0000, Tony Lance <judemarie(a)bigberthathing.co.uk> Gave us: >Big Find your own thread to SPAM in, dipshit.
From: nonsense on 6 Mar 2007 21:23 MassiveProng wrote: > On Tue, 06 Mar 2007 08:07:00 -0600, "nonsense(a)unsettled.com" > <nonsense(a)unsettled.com> Gave us: > > >>It is a hard disk controller and more, a superset rather >>than "something different" that you'd prefer to make it. > > > > It is a bus controller that becomes a hard drive controller per se > once hard drives are included on its bus. That's the same as saying that a car isn't a car until it is being driven.
From: jmfbahciv on 7 Mar 2007 06:55
In article <2dab6$45ed7ada$4fe701c$6184(a)DIALUPUSA.NET>, "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: >jmfbahciv(a)aol.com wrote: > >> In article <esij9m$9en$1(a)blue.rahul.net>, >> kensmith(a)green.rahul.net (Ken Smith) wrote: >> >>>In article <eshesp$8qk_004(a)s787.apx1.sbo.ma.dialup.rcn.com>, >>><jmfbahciv(a)aol.com> wrote: >>> >>>>In article <eshe15$l1t$5(a)blue.rahul.net>, >>>> kensmith(a)green.rahul.net (Ken Smith) wrote: >>>> >>>>>In article <MPG.2055feeb3db1e22498a066(a)news.individual.net>, >>>>>krw <krw(a)att.bizzzz> wrote: >>>>>[....] >>>>> >>>>>>Much of the "controller" is on the chipset these days, oh >>>>>>MassivelyWrong one. >>>>> >>>>>I know that appearing to agree with MissingProng is a strong indication of >>>>>error but there is a point that I would like to make here. >>>>> >>>>>Way back in the mists of time, there was electronics for disk drives we >>>>>called the "controller". This electronics was much simpler than the >>>>>electronics used related to disk drives today. >>>> >>>>And one controller could have many devices hanging off it. >>>>Apparently, that doesn't happen at the moment. From your >>>>descriptions, it appears there a 1::1 restriction. >>> >>>Yes, today, electronics is much cheaper so we can take advantage of this. >> >> >> This isn't a feature. This kind of restriction evolved because >> the gear was cheap. Removing the parallelism of hardware >> pathways was the trade off. > >Yet there is the advantage of speed that massive parallelism >hampers by its sheer bulk. Still a trade off however. Speed is uninteresting if you don't have a way to get the bits from here to there. :-) Having more than one path allows the system to keep functioning even if one of the pathways breaks. /BAH |