iverson@xstor.UUCP (Tim Iverson) (03/25/90)
>>tmottonen@cc.helsinki.fi writes: >> >> [paraphrased] is it possible to have both a SCSI-adapter >> and an MFM-controller in the same machine? >> >> Thanks, Teemu. >jca@pnet01.cts.com (John C. Archambeau) replies: > >I don't know the idiosyncrasies of how a SCSI host adaptor works in a >PC/AT/386, but I'm willing to bet that the host adaptor and ST412/506 MFM >controller would have IRQ and port address wars ... >... I personally wouldn't do it. With respect to controllers, the rule of >thumb is this...assume the manufacturer is stupid (or arrogant) and will not >allow any way for you to have more than one drive controller in your machine. >[... more mis-information deleted ...] > > // JCA > ** ARPANET : crash!pnet01!jca@nosc.mil | mine. Bill Gates couldn't buy > ** INTERNET: jca@pnet01.cts.com | it, but he could rent it. :) > ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca I just couldn't pass this one up. The scsi h/a would have IRQ and port wars with an ST506 controller? This is pure bullshit. Most scsi host adapters are *designed* to work in systems with existing ST506 controllers. SCSI H/A manufacturers are not arrogant idiots trying to lock you into their own platform - for the most part they actually go out of their way to make sure that their boards are comptible with existing platforms. Because of this, most H/As are easier to install and more reliable than their ST506 counterparts. I have used Storage Dimensions' Data Cannon 800, Future Domain's TMC 830 and MCS 350, and Adaptec's 1540 derivatives extensively. I have played with many others, but I do not posses sufficient information on them to provide a recomendation. This is what I can attest to: DC800 - very good for supported OSes. SDI drivers support DOS and Novel only. Low overhead, but no 1st party DMA. DOS can run w/o SDI's SpeedStor driver, but you don't get added features (Erasable Optical support, fast compare after write, automatic reallocation of bad blocks on write, etc...). [BTW: I wrote the SpeedStor driver for the DC800 :-)]. FutDom - all products have serious bugs that require special driver workarounds (verify function doesn't work, randomly pokes bytes into memory under certain conditions, etc.) Adaptec - high overhead (1ms per command?), but has 1st party DMA (good for UNIX - Novel support unknown) and is reliable. On board BIOS supports only 2 drives, but Adaptec driver will support 7. SDI is working on adding 1540/1640 support to SpeedStor. N.B. I have cross-posted this to comp.periphs.scsi. Hopefully, some of the knowledgeable people reading that group will deign to comment. - Tim Iverson {decwrl,uunet}!xstor!iverson
jca@pnet01.cts.com (John C. Archambeau) (03/26/90)
iverson@xstor.UUCP (Tim Iverson) writes: >>>tmottonen@cc.helsinki.fi writes: >>> >>> [paraphrased] is it possible to have both a SCSI-adapter >>> and an MFM-controller in the same machine? >>> >>> Thanks, Teemu. > >>jca@pnet01.cts.com (John C. Archambeau) replies: >> >>I don't know the idiosyncrasies of how a SCSI host adaptor works in a >>PC/AT/386, but I'm willing to bet that the host adaptor and ST412/506 MFM >>controller would have IRQ and port address wars ... >>... I personally wouldn't do it. With respect to controllers, the rule of >>thumb is this...assume the manufacturer is stupid (or arrogant) and will not >>allow any way for you to have more than one drive controller in your machine. >>[... more mis-information deleted ...] >I just couldn't pass this one up. The scsi h/a would have IRQ and port wars >with an ST506 controller? This is pure bullshit. Most scsi host adapters >are *designed* to work in systems with existing ST506 controllers. SCSI H/A >manufacturers are not arrogant idiots trying to lock you into their own >platform - for the most part they actually go out of their way to make sure >that their boards are comptible with existing platforms. Because of this, >most H/As are easier to install and more reliable than their ST506 >counterparts. > >I have used Storage Dimensions' Data Cannon 800, Future Domain's TMC 830 and >MCS 350, and Adaptec's 1540 derivatives extensively. I have played with >many others, but I do not posses sufficient information on them to provide >a recomendation. This is what I can attest to: > > DC800 - very good for supported OSes. SDI drivers support DOS > and Novel only. Low overhead, but no 1st party DMA. DOS > can run w/o SDI's SpeedStor driver, but you don't get added > features (Erasable Optical support, fast compare after write, > automatic reallocation of bad blocks on write, etc...). > [BTW: I wrote the SpeedStor driver for the DC800 :-)]. > > FutDom - all products have serious bugs that require special driver > workarounds (verify function doesn't work, randomly pokes > bytes into memory under certain conditions, etc.) > > Adaptec - high overhead (1ms per command?), but has 1st party DMA > (good for UNIX - Novel support unknown) and is reliable. > On board BIOS supports only 2 drives, but Adaptec driver > will support 7. SDI is working on adding 1540/1640 support > to SpeedStor. I based my assertion on trying to hang an ESDI and ST412/506 controller at the same time on the same machine. Doesn't work too hot. Also, I don't care for Adaptec's products since they have lousy tech support. You might have good luck with them, but I personally stick with only Western Digital, is the same true for the WD7000 SCSI Host Adaptor? If so, then I'd love to hear it. Also, I didn't say that what I said was the gospel truth, just an educated guess considering I know some of the horrors of SCSI and the IBM compatable domain. I am not convinced that it is fully implemented or supported as well as it should be which is why I stay away from SCSI with respect to IBM compatables. I also based my assertion of the KISS philosophy of system configuration (keep it simple, stupid). Granted, you may be able to do it, but also think from the practical standpoint, why would you want to? You have this slow drive that's running ST412/506 MFM and a SCSI controller with possibly a Wren IV to VI running like a bat out of hell. I wouldn't do it just for the sake of system performance if I knew 100% in my mind that I wasn't going to have any problems with the SCSI host adaptor and the IBM compatable in question. As for Novell, the only thing that is 100% Novell approved is Novell's DCB board. It's also the only thing that currently works with NetWare 386. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | My opinions are exactly that, ** ARPANET : crash!pnet01!jca@nosc.mil | mine. Bill Gates couldn't buy ** INTERNET: jca@pnet01.cts.com | it, but he could rent it. :) ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
iverson@xstor.UUCP (Tim Iverson) (03/27/90)
In article <1969@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >I based my assertion on trying to hang an ESDI and ST412/506 controller >at the same time on the same machine. Doesn't work too hot. This is correct. Both ESDI and ST506 typically attempt to be WD1003 compatible, since clone BIOSes support that register set directly. This is why most *ESDI* and ST506 boards have "IRQ and i/o port wars". Most SCSI board vendors have chosen to *not* support the WD1003 register set and instead to put their own BIOS on the adapter. This makes the boards more hardware compatible, but more expensive to design. >[...] I personally stick with only Western Digital, is >the same true for the WD7000 SCSI Host Adaptor? If so, then I'd love to hear >it. I've used the wd7000(FASST - a misnomer); I don't care for it. I haven't used it sufficiently to comment further - unless lotsa people mail and beg me for my purely subjective judgements :-). >Also, I didn't say that what I said was the gospel truth, just an >educated guess considering I know some of the horrors of SCSI and the IBM >compatable domain. Unfortunetly, in the this area your educated guess is serious misinformation at best - at worst, it is a bald lie. If you cannot restrict yourself to reporting facts, do not post. >[...] Granted, you may be able to >do it, but also think from the practical standpoint, why would you want to? >You have this slow drive that's running ST412/506 MFM and a SCSI controller >with possibly a Wren IV to VI running like a bat out of hell. I wouldn't do >it just for the sake of system performance [...] In your previous article, you lambasted vendors for second guessing the users' needs. Here, you are guilty of that yourself. Perhaps the user will use the quick subsystem for work and the slow one for backup (after all, it works and he already owns it). Also, the presence of an ST506 subsytem in a system with a SCSI subsystem in no way degrades the performance of the SCSI subsystem - the two are mutually exclusive. In a multitasking OS, if the subsystems are used concurrently, and if the SCSI H/A does 1st party DMA, then the 1003 compatible subsystem will degrade overall system performance more than the SCSI subsytem. When the 1003 subsystem is not being used, system performance is not impacted at all. Running slowly during backups usually considered acceptable. >As for Novell, the only thing that is 100% Novell approved is Novell's DCB This is another outright lie. SDI markets both ESDI and SCSI (non DCB) subsystems that are 100% certified. SDI also markets a 100% certified fileserver (basically a 33Mhz 386 optimized for disk i/o). > // JCA > ** ARPANET : crash!pnet01!jca@nosc.mil | mine. Bill Gates couldn't buy > ** INTERNET: jca@pnet01.cts.com | it, but he could rent it. :) > ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jc To paraphrase Joe Friday, "Just the facts, man". Being wrong is no crime, its the degree of the act that makes it a felony. Please stick to what you know to be true when you post as an "authority" on a subject. - Tim Iverson uunet!iverson!xstor
jca@pnet01.cts.com (John C. Archambeau) (03/27/90)
iverson@xstor.UUCP (Tim Iverson) writes: >In article <1969@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >>I based my assertion on trying to hang an ESDI and ST412/506 controller >>at the same time on the same machine. Doesn't work too hot. > >This is correct. Both ESDI and ST506 typically attempt to be WD1003 >compatible, since clone BIOSes support that register set directly. This is >why most *ESDI* and ST506 boards have "IRQ and i/o port wars". Most SCSI >board vendors have chosen to *not* support the WD1003 register set and >instead to put their own BIOS on the adapter. This makes the boards more >hardware compatible, but more expensive to design. What if you're using an OS that can only use the BIOS at power on to boot such as *nix? Then you need a driver for each manufacturer's SCSI host adaptor to run under this vendor's operating system. Obviously the vendor isn't going to provide it unless it is a commonly used piece of hardware. The onboard controller BIOS can not be used for something such as Unix. So what do you do then? You have to go through what controllers are supported by the OS and prey the one you want has a driver either provided by the manufacturer of the controller or the vendor of the OS. Anybody who needs SCSI such as hell isn't going to use DOS with it since it would be a waste. >>Also, I didn't say that what I said was the gospel truth, just an >>educated guess considering I know some of the horrors of SCSI and the IBM >>compatable domain. > >Unfortunetly, in the this area your educated guess is serious misinformation >at best - at worst, it is a bald lie. If you cannot restrict yourself to >reporting facts, do not post. The word here is recommendation. Anything I post I wouldn't recommend doing for a customer or myself. We stay away from SCSI totally with the only exception being this one customer that has everything SCSI for performance reasons in the IBM compatable domain. I am not convinced of how well SCSI is supported in the IBM compatable domain. Every manufacturer does their SCSI host adaptor differently which means problems with respect to finding drivers for alternate operating systems. >>[...] Granted, you may be able to >>do it, but also think from the practical standpoint, why would you want to? >>You have this slow drive that's running ST412/506 MFM and a SCSI controller >>with possibly a Wren IV to VI running like a bat out of hell. I wouldn't do >>it just for the sake of system performance [...] > >In your previous article, you lambasted vendors for second guessing the >users' needs. Here, you are guilty of that yourself. Perhaps the user >will use the quick subsystem for work and the slow one for backup (after >all, it works and he already owns it). Also, the presence of an ST506 >subsytem in a system with a SCSI subsystem in no way degrades the >performance of the SCSI subsystem - the two are mutually exclusive. > >In a multitasking OS, if the subsystems are used concurrently, and if the >SCSI H/A does 1st party DMA, then the 1003 compatible subsystem will >degrade overall system performance more than the SCSI subsytem. When the >1003 subsystem is not being used, system performance is not impacted at >all. Running slowly during backups usually considered acceptable. Multitasking operating systems don't use the BIOS. Unless the onboard controller BIOS is designed to run in 286/386 protected mode, you're going to need a driver for the SCSI host adaptor you're using, whether it be OS/2 (gag) or *nix. Again, the problem of "where do I get that damned driver to run this controller with this OS?" comes into play. If there's no driver for the controller, you are sunk. >>As for Novell, the only thing that is 100% Novell approved is Novell's DCB > >This is another outright lie. SDI markets both ESDI and SCSI (non DCB) >subsystems that are 100% certified. SDI also markets a 100% certified >fileserver (basically a 33Mhz 386 optimized for disk i/o). Try using anything other than Novell's DCB board with NetWare 386, you will find that it will not work by longshot. No drivers for any other board other than the DCB. This is from Novell, this is fact since we did it. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | My opinions are exactly that, ** ARPANET : crash!pnet01!jca@nosc.mil | mine. Bill Gates couldn't buy ** INTERNET: jca@pnet01.cts.com | it, but he could rent it. :) ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
stevel@haddock.ima.isc.com (Steve Ludlum) (03/27/90)
In article <1977@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >What if you're using an OS that can only use the BIOS at power on to boot such >as *nix? Then you need a driver for each manufacturer's SCSI host adaptor to >run under this vendor's operating system. Obviously the vendor isn't going to >provide it unless it is a commonly used piece of hardware. The onboard >controller BIOS can not be used for something such as Unix. So what do you do >then? You have to go through what controllers are supported by the OS and >prey the one you want has a driver either provided by the manufacturer of the >controller or the vendor of the OS. Anybody who needs SCSI such as hell isn't >going to use DOS with it since it would be a waste. Just put an Adaptec 1542 in your IBM 386/AT clone and run ISC 386/ix, soon to be called UNIX. It also supports Future Domain though I have never used it. UNIX does use the on board BIOS on the Adaptec for booting, then it runs a custom UNIX own driver. Works like a charm and I get over 300K bytes per second THROUGH the file system, over 500K/sec to the raw device. I don't know about other vendors support of booting a SCSI out of the software box. Your milage may vary with drive speed and first party DMA. >Try using anything other than Novell's DCB board with NetWare 386, you will >find that it will not work by longshot. No drivers for any other board other >than the DCB. This is from Novell, this is fact since we did it. I have never tried running Novel, I think I saw a Novell package once, but I would never try to run it. Ugh DOS. >iverson@xstor.UUCP (Tim Iverson) writes: > "Just the facts" Please only fact not possibly wrong guesses. These opinions are mine and the experience is mine. ISC only unknowingly supplied an employee, me, the software. -- Steve Ludlum stevel@ima.isc.com Interactive Systems 617-252-5895
iverson@xstor.UUCP (Tim Iverson) (03/30/90)
In article <1977@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >iverson@xstor.UUCP (Tim Iverson) writes: >What if you're using an OS that can only use the BIOS at power on to boot such >as *nix? Then you need a driver for each manufacturer's SCSI host adaptor to >run under this vendor's operating system. Well, we were talking about PC's running DOS, if you recall. I guess it's my own fault for dragging Novel in as an aside. Yes, you need a driver. >Obviously the vendor isn't going to provide it unless it is a >commonly used piece of hardware. I assume you mean a popular OS (not just hardware) - the board itself restricts the HW options. What you mean is not really true. The vendors that are committed to SCSI provide drivers for the popular OSes available on the platforms their boards run under (e.g. Adaptec). >[...] Anybody who needs SCSI such as hell isn't going to use DOS with it > since it would be a waste. I don't see the connection between DOS and SCSI and waste. What is being wasted? As far as SCSI drives on DOS are concerned, installation is much, much easier than ESDI. Reliability and performance of the drive is identical to comparable ESDI drives (e.g. a Maxtor 8760E performs the same as a Maxtor 8760S). Reliability and performance of the SCSI subsystem is usually much better. Price is comparable, it not identical. >The word here is recommendation. Anything I post I wouldn't recommend doing >for a customer or myself. You wouldn't recommend doing what you say to do in your postings? :-) You probably meant something like "I was only making recomendations ...". If this was true, then perhaps I was hasty with the blow-torch, but I think not. The tone of your article presented your "recomendations" as fact. If you had said something like: "I know nothing about SCSI on PCs, but this is what I *imagine* to be true ...", your original article would have been more factual. It's ok to grant the benifit of the doubt to others, but not to yourself. >[...] I am not convinced of how well SCSI is supported in the IBM >compatable domain. Every manufacturer does their SCSI host adaptor >differently which means problems [...] You don't think the 1003 "compatible" controllers have problems? Ha! We continually need to update the SpeedStor driver and program to work around problems each vendor introduces into each board. Typically, these are not HW bugs, but questions about interpreting the 1003 design - it is not a well specified standard (for a long while it was the only one, though). WD and Adaptec are not the worst offenders in the area of 1003-style controllers, but both have plenty of problems - some of them fairly serious. >Multitasking operating systems don't use the BIOS. Right. True. Correct. I assumed you knew that I knew this. Sorry if I gave the impression that I didn't - probably shouldn't have granted myself the benifit of the doubt. :-) >[[paraphrased] Unless the board has a proteced mode BIOS, you] >need a driver for the SCSI host adaptor you're using [...] I haven't heard of any protected mode BIOSes (or OSes that use them), but that's not to say it's impossible. >Again, the problem of "where do I get that damned driver to run this >controller with this OS?" comes into play. This is not hard unless the OS is new or obscure. >Try using anything other than Novell's DCB board with NetWare 386, you will >find that it will not work by longshot. This (386 Netware, as opposed to 286) falls under the "new" category. Expect lotsa drivers real soon ... > // JCA > ** ARPANET : crash!pnet01!jca@nosc.mil | mine. Bill Gates couldn't buy > ** INTERNET: jca@pnet01.cts.com | it, but he could rent it. :) > ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca - Tim Iverson uunet!xstor!iverson