wsinpdb@eutws1.win.tue.nl (Paul de Bra) (02/01/90)
In article <15@omen.UUCP> caf@omen.UUCP (WA7KGX) writes: >... >With SCO Unix, Micronics 33 mHz 386, 1542A and a Wren V I get better than >500 kbytes/sec on "cp bigfile /dev/null" if the system is quiet. That's >4MB. I tried the same on my Everex Step 386/25, copying a 34Mbyte file to /dev/null. This was using the 2322 ESDI controller and the Wren V ESDI drive. I got 435 kbytes/sec. (it was also with AT&T Unix, not SCO) So ESDI users should not feel like they missed a great opportunity by not starting off with SCSI. I agree that SCSI may be better from a conceptual point of view, but ESDI in a PC (single user, not more than 2 disks needed, etc.) performs more than well enough. Paul. (debra@research.att.com)
neese@adaptex.UUCP (02/02/90)
The following is the monthly list of what is on adaptex.
adaptex Any ACU BAUD 8174886893 -\d\d\d-gin:-BREAK\d\d\d-gin:-BREAK\d\d\d-gin: suucp
Replace the word BAUD with whatever is appropriate. Adaptex cycles from
9600->2400->1200.
To get any of the files, use:
uucp adaptex!~/file /usr/spool/uucppublic/file
or
uucp adaptex!/usr/spool/uucppublic/scsiutil/file /usr/spool/uucppublic/file
To get the detailed list and descriptions of what is on adaptex, request the
"list" file.
-------------------------------------------------------------------------------
~/GETDEVS.EXE.Z Size: 11013 Oct 11 09:12 GETDEVS.EXE.Z
UD 1/25/1990 Size: 11190 Jan 25 16:57 GETDEVS.EXE.Z
- More robust and now works on fast 386 and 486 machines.
Shows all SCSI devices connected to the adapter.
-------------------------------------------------------------------------------
~/GRDRIVE.EXE.Z Size: 26244 Oct 11 09:12 GRDRIVE.EXE.Z
~/GREAD.EXE.Z Size: 26533 Oct 11 09:13 GREAD.EXE.Z
~/GWRITE.EXE.Z Size: 26591 Oct 11 09:13 GWRITE.EXE.Z
Benchmark type utilities, for all type of drives.
-------------------------------------------------------------------------------
~/SCSI.EXE.Z V6.0 Size: 37507 Oct 11 09:12 SCSI.EXE.Z
UD 12/08/1989 V6.1 Size: 37466 Dec 18 09:05 SCSI.EXE.Z
- Corrects program to work on machines faster than 20Mhz.
UD 1/25/1989 V6.2 Size: 38707 Jan 25 16:57 SCSI.EXE.Z
- More robust cleanup after itself. Now tested to work on 33 Mhz
386 and 486 machines.
SCSI Diagnostics
-------------------------------------------------------------------------------
~/SCSICNTL.EXE.Z V4.4 Size: 49087 Oct 11 09:12 SCSICNTL.EXE.Z
UD 12/08/1989 V4.5 Size: 49104 Dec 12 08:44 SCSICNTL.EXE.Z
- Corrects program to work on machines faster than 20Mhz.
UD 1/22/90 V4.6 Size: 49070 Jan 22 08:54 SCSICNTL.EXE.Z
- Adds support for the CDC Wren VII drive.
UD 1/25/90 V4.8 Size: 50208 Jan 25 16:57 SCSICNTL.EXE.Z
- Corrected the support for the Wren VII drive. They changed the
name in the inquiry data to IMPRIMIS. More robust cleanup routine
and general improvements to allow fast 386 and 486 machines to work.
Option 11 to get the adapter configuration returns more data than
ever.
Mode Sense/Select SCSI Control Program
-------------------------------------------------------------------------------
~/scsicntl.doc.Z Size: 12116 Nov 4 09:37 scsicntl.doc.Z
UD 1/25/1990 Size: 12594 Jan 25 16:50 scsicntl.doc.Z
- Added a line to generate a table of contents and also some other
additions to cover the 4.8 version of SCSICNTL.
Troff doc for SCSICNTL
-------------------------------------------------------------------------------
~/SCSIHA.SYS.Z Size: 1160 Oct 11 09:22 SCSIHA.SYS.Z
Windows386 Driver
-------------------------------------------------------------------------------
~/readme.Z Size: 298 Oct 25 10:43 readme.Z
The readme file for the usage of the SCSIHA.SYS driver.
-------------------------------------------------------------------------------
~/SETSCSI.EXE.Z Size: 7633 Oct 11 09:24 SETSCSI.EXE.Z
Used to set the DMA rate, bus on/off times
-------------------------------------------------------------------------------
~/@0F1F.ADF.Z Size: 1732 Oct 11 09:22 @0F1F.ADF.Z
ADF file for the AHA-1640
-------------------------------------------------------------------------------
~/inq.Z Size: 8658 Dec 19 16:24 inq.Z
Program for SCO 2.3GT to display INQUIRY info for any SCSI device.
-------------------------------------------------------------------------------
~/1540USR.MAN.Z Size: 92083 Jan 26 17:08 1540USR.MAN.Z
Ascii version of the AHA1540 User's Manual.
-------------------------------------------------------------------------------
~/sco.patches.Z Size: 2825 Jan 29 09:18 sco.patches.Z
A list of patches to allow a user to tune the SCSI driver.
-------------------------------------------------------------------------------
~/1540CPU.LIST.Z Size: 1158 Jan 30 08:27 1540CPU.LIST.Z
A list of Adaptex tested CPU's and the 154x adapter.
-------------------------------------------------------------------------------
~/1540DRV.LIST.Z Size: 1304 Jan 30 08:30 1540DRV.LIST.Z
A list of drives that have been tested with the 154x adapter.
-------------------------------------------------------------------------------
~/sds3.desc.Z Size: 1046 Jan 31 13:26 sds3.desc.Z
A troff file containing a one page description of all SDS options available
from Adaptec.
-------------------------------------------------------------------------------
Roy Neese
Adaptec Central Field Applications Engineer
UUCP @ {texbell,attctc}!cpe!adaptex!neese
merch!adaptex!neese
uunet!swbatl!texbell!merch!adaptex!neeselarry@nstar.UUCP (Larry Snyder) (02/02/90)
>So ESDI users should not feel like they missed a great opportunity by not >starting off with SCSI. I agree that SCSI may be better from a conceptual I agree 100%. Many times I've seen ESDI subsystems exceed throughput of SCSI ones.
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (02/06/90)
In article <25c97303:579.6comp.unix.xenix;1@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >So ESDI users should not feel like they missed a great opportunity by not >starting off with SCSI. I agree that SCSI may be better from a conceptual I agree 100%. Many times I've seen ESDI subsystems exceed throughput of SCSI ones. I agree 70%. :-) Throughput in sequential reads from the disc is not the only measure, and there are funny consequences. Latency may be important; a multithreaded SCSI controller with two drives can overlap seeks and transfers. Random access may be important, for example for directory tree scans, databases. Read ahead may slow down random accesses. Writing may be important, even if reading is prevalent. Track buffering, nairvely implemented, may slow down writes. I/O thru the filesystem may be important, actually is, usually. There are already wide variations between buffered and raw disc accesses; file system accesses have a different profile again. SCSI is more sophisticated, and will keep better performance is less favourable conditions. MSDOS, single user UNIX, editing and compiles, tend not to exploit the advantages of SCSI. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
karl@ddsw1.MCS.COM (Karl Denninger) (02/06/90)
In article <25c97303:579.6comp.unix.xenix;1@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >>So ESDI users should not feel like they missed a great opportunity by not >>starting off with SCSI. I agree that SCSI may be better from a conceptual >I agree 100%. Many times I've seen ESDI subsystems exceed throughput of >SCSI ones. And more than a few times I've seen SCSI blow the doors off ESDI. What's your effective speed (time) reported in the test above with your ESDI subsystem? How is it affected by two or more running on >different< drives on the same controller? Can you really exceed 1 MB/second through the block device? (RAW device information is meaningless; filesystems don't read and write through them!) Then add in the fact that you can get a $820 150MB tape backup for SCSI, versus almost $1300 for the >same< drive in a "board + drive" combination! Try backing up the system with both combinations -- you'll find the SCSI device machine is actually usable during the backup -- while the other system is crawling! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
wsinpdb@eutws1.win.tue.nl (Paul de Bra) (02/07/90)
In article <1990Feb5.220150.374@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >... >Then add in the fact that you can get a $820 150MB tape backup for SCSI, >versus almost $1300 for the >same< drive in a "board + drive" combination! >Try backing up the system with both combinations -- you'll find the SCSI >device machine is actually usable during the backup -- while the other >system is crawling! My experience is quite the opposite, which only means that it's not a SCSI versus non-SCSI problem. On several Suns, not only old ones like the 3/160 but also the 386i/150 and /250 the system is crawling when you use the tape drive, and with an exabyte it's even worse. On my 386 box (with AT&T Unix, not Xenix) I have yet to notice any performance drop when I'm reading or writing the tape. This is using an Everex controller and a Wangtek drive. I guess it's a matter of writing efficient device drivers, not of chosing SCSI or not. Paul. (debra@research.att.com)