neese@cpe.UUCP (10/10/88)
>for our '286 machines. A local dealer has recommended the >Future Domain SCSI controller and claims this works with >Xenix/Unix and that someone has this setup using Microport. > Has anyone had any experience with this board ? The FD board is a nice board, but it is a dumb board and requires the COPU to do everything (i.e. high overhead). > Does this imply a special version of Xenix ? I think, in this case, it is a generic SCO product that you can run this with. > Is this board related in anyway to the Tandy SCSI board ? > (I though the Tandy board was micro channel only) No, the Tandy board is the Adaptec SCSI AHA-1540 board. Very intelligent. It is an AT board, the MC board is not shipping yet. > Is there a better Xenix/SCSI combination ? Without sounding like a commercial, I will elaborate on the features of the Tandy board. The board has a programmable high speed DMA (up to 10MBytes/sec), command queuing (up to 255 commands), transparent SCSI bus arbitration, programmable bus on/off times, INT13 compatible BIOS, programmable mailbox architecture, automatic request sense information for errors, async/sync support transparently, and some other features that require hard drive vendors to implement. > Any clues or experiences would be appreciated. I'd love to >use SCSI as my main disk interface, but am I going to have to >run Microport to do this ? Tandy sells a version of SCO (2.2.4) which has support for the AHA-1540 (Tandy 25-4161) built in. You can boot from the SCSI drive or use it as a secondary and boot from an ST-506 drive. 2.2.4 and 2.2.3 are virtually the same except for the SCSI support in 2.2.4. The SCSI driver for 2.2.4 is a true multi-threaded driver. The driver also supports several SCSI tape drives. Neal Nelson has benchmarked a Tandy 4000 (16Mhz 386) with a SCSI 80MB and 170MB. Call them for the results. We have been using the SCSI stuff here for about 6 months and haven't had a problem. One of the systems is configured with a 80MB, 344MB and 150MB tape. Another system is configured with a 40MB and 80MB drives. The systems really run quite well (translate to: scream). One system is a news/note gateway and the other is a 16 user system. Both see an extreme amount of disk I/O and we haven't had any trouble with either. Of course in all fairness, we are an engineering site with several very experienced Xenix people on board, but I don't see why anyone would have problems with the implementation. Roy Neese Tandy Computer Product Engineering UUCP@ {killer, ninja}!cpe!neese
neese@cpe.UUCP (10/12/88)
>The problem is not Xenix, but the way IBM designed the AT. What happens >is that most controllers use the same interrupt. The AT cannot support >multiple devices with the same interrupt. Also, they both might be using >the same address space. Either or both of these situations will cause >problems. Perhaps some of the hardware types will be able to shed some >more light on the matter. Actually, the real problem is: 1) In order for SCO xenix to support DOS partitions they had to stick with the DOS kinda things. AT BIOS's only support 2 hard drives,...so they had to live with that restriction. 2) The BIOS is used by Xenix to do the boot and load the kernel. This implies that you must have a hard drive scheme that is compatible with the BIOS architecture. 3) MS-DOS only understands 2 hard drives, so for compatibility sakes, SCO was forced to use the same scheme so they could support DOS and Xenix on the same drives. MS-DOS has to be able to understand the partition table that Xenix creates or they couldn't co-exist on the same drive. Now some of this stuff can be worked around. In SCO Xenix 2.2.4, the OS supports multiple HD controllers. (SCSI and ST-506). A newer version of 2.3 called 2.3GT will be able to support ST-506, ESDI, and SCSI. This is all done without breaking any compatibility but it did require the engineers at SCO to do some very creative things to the OS. So if you want to point fingers, IBM did the first stupid thing by only allowing the AT BIOS to support only 2 hard drives. Of course, Microsoft followed suit and created a DOS that could only deal with 2 physical hard drives, and then Western Digital added fuel to the fire by creating a line of controllers that only supported 2 hard drives. This is how we got here today. Roy Neese Tandy Computer Product Engineering UUCP@ killer!{ninja, merch}!cpe!neese
chip@ateng.ateng.com (Chip Salzenberg) (10/14/88)
According to neese@cpe.UUCP: >>Future Domain SCSI controller [...] >The FD board is a nice board, but it is a dumb board and requires the CPU >to do everything (i.e. high overhead). Definitely. >> Does this imply a special version of Xenix ? >I think, in this case, it is a generic SCO product [...] Nope. You need a *running* Xenix system to create a FD kernel. >Tandy sells a version of SCO (2.2.4) which has support for the AHA-1540 >(Tandy 25-4161) built in. Also, unless I miss my guess, SCO 2.3 supports the AHA-1540. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
neese@cpe.UUCP (10/18/88)
>>Perhaps I was mistaken about 2.3 including Adaptec support. My info was >>second hand. > >XENIX 386 2.3 has several different versions, not all of which are out yet. >There will be a version released which supports the Adaptec card for >boot and root devices. > >>The slowness may be due to the [Future Domain] controller or the driver >>or both. In truth, >>I don't care; it's just too slow. I'm ditching Future Domain as soon as >>possible. > >This is good and useful information. It's also in direct contradiction >to Future Domain's literature, which makes the point that PIO can often >be faster than DMA on a 386AT architecture due to its ability to handle >arbitrary block transfers into virtual memory versus breaking up a >request into 4kb physical DMA transfers. I'd be interested to know >what "too slow" is here. How does it compare to your experience >with ST506 controllers under XENIX? Let's make some general purpose statements. Dumb SCSI adapters are akin to dumb serial ports. Intelligent SCSI adapters do for disk I/O what smart serial adapters do for serial I/O. Offload the CPU. The AHA-1540 offloads the SCSI low-level functions. The CPU doesn't deal with data transfers, bus arbitration, phase changes, error handling, handshakes, and multiple interrupts. Translates to low CPU overhead. A dream for the Unix/Xenix system. The only limitation of performance is the quality of the device driver and the speed of the CPU. The true measure of disk performance for Unix systems is the overhead associated with disk I/O. The lower disk overhead, the better overall performance for the system. The only benefit an ESDI interface gains over ST-506 is a higher data rate and usually better seek times. In standard implementations, ESDI and ST-506 have almost the same disk overhead for the CPU. We tested this theory by running a program that mixed calculations with disk I/O and a 16Mhz 386 with a AHA-1540 SCSI adapter ran up to 53% faster than a 20Mhz 386 with an ESDI drive. Seek times were eqivulent in both drives. Roy Neese Tandy Computer Product Engineering UUCP@ killer!ninja!cpe!neese
neese@cpe.UUCP (10/19/88)
>First, Future Domain sells 2 types of controllers. One type is a >multithread capable controller, the TMC-830/840/880 family. >The other type is single threaded, the TMC-870 is this type. > >Someone claimed that Future Domain controllers on Xenix were slow. This >person also said he is using a TMC-870. He is correct, Xenix with the >870 is slow, we do not recommend the 870 for use on Xenix or Unix. It is >primarily designed to be a low cost DOS product. > >The TMC-830/840/880 performance is very very good on Xenix. Quite on par >with the AHA-1540 Adaptec board which has been mentioned in past letters. >These boards support multi-thread operations, as does the driver. The driver >does not have wait loops in it as someone erroneously conjectured. Isn't it true that all the SCSI arbitration for the Future Domain adapter is done by software? I think this is the case, which still translates to a high CPU overhead for the driver. >(bunch of text deleted) >9) Xenix 2.2.4 has the multi fixed disk driver facilities built into it, > but this release is only available with Tandy 1000's. First, 2.2.4 is availbale from SCO to OEM's. It is currently sold by Tandy for use on the 4000/4000LX CPU's. It does support multiple controllers as will 2.3GT when it becomes available. We will be doing some performance comparisons between the AHA-1540 and Future Domain products under Xenix, and I invite everyone on the net who is interested, to submit programs that they think best measures the performance of a system. I will be glad to post the results of this when it is done. Let's say, we will start this 10/28/88. Anyone who wants thier program compared to the AHA-1540 and TMC-830/840/880 should have thier program submitted before 10/28/88. Let's settle this matter once and for all. Roy Neese Tandy Computer Product Engineering UUCP@ killer!ninja!cpe!neese