allred@ut-emx.UUCP (Kevin L. Allred) (07/08/89)
I'm putting together a low end workstation for my personal use at home. It will have a 386SX, 4MB memory and monochrome VGA graphics. Initially I plan to just run MSDOS, but soon I would like to run UNIX. I currently am considering hard drives in the range of 65 to 80 MB. I was only considering an RLL drive with 1:1 interleve controller until I had pointed out to me that Segate has recently started marketing a low cost SCSI addaptor (ST01 and ST02) suitable for use with its ST296N 80MB hard disk. This combination reportedly offeres about 750 KB/sec transfer rate, which is comparable to the 1:1 interleve RLL transfer rate, and it is more cost effective. Apparently the SCSI addaptor works fine under DOS, but I have already had related to me that it probably won't work with UNIX because of lack of drivers (I heard that was a problem common to most SCSI boards even the expensive intelligent ones like the WD7000). Are the various UNIX vendors developing drivers, so that I don't need to worry about this, or should I stick with the RLL controller and disks? -- Kevin Allred allred@emx.cc.utexas.edu allred@ut-emx.UUCP
byronl@copper.MDP.TEK.COM (Byron Lunz) (07/08/89)
In article <14978@ut-emx.UUCP> allred@ut-emx.UUCP (Kevin L. Allred) writes: >I'm putting together a low end workstation for my personal use at home. >It will have a 386SX, 4MB memory and monochrome VGA graphics. ... >I was only considering an RLL drive with 1:1 interleve controller until >I had pointed out to me that Segate has recently started marketing a >low cost SCSI addaptor (ST01 and ST02) suitable for use with its >ST296N 80MB hard disk. This combination reportedly offeres about 750 >KB/sec transfer rate, which is comparable to the 1:1 interleve RLL >transfer rate, and it is more cost effective. Apparently the SCSI I received my new Gateway 2000 386/20 a few days ago. It arrived with a Seagate ST296N and SCSI controller (not sure of the model #). Transfer rate was one of my reasons for purchasing this system, and I was assured prior to the purchase by the salesperson that I could expect 800KB/sec. I was quite disappointed when both Spintest and Coretest 2.7 gave me data transfer rates of 440-460KB/sec! Then, just today Mark Davis <davis@cs.unc.edu>, reported that some users are seeing transfer rates of 950KB/sec! The interesting part is that when I called Gateway, the salesman immediately began reciting what sounded like a prepared statement to the effect that Seagate had lied to them! Then he quickly offered me a ST4096/DTC controller combo as a replacement, with a transfer rate of 550KB/sec. It's in the mail. If someone out there is actually seeing transfer rates around or over 800KB/sec, I'd sure like to hear about it. P.S. The drive documentation supplied with my system says the interleave is 1:1. And the access time, rated at 28ms, is measured at 33.7ms by Coretest. -- Byron Lunz Tektronix Logic Analyzer Division byronl@copper.MDP.TEK.COM Beaverton, Oregon
ylo@sauna.HUT.FI (Tatu Yl|nen) (07/10/89)
In article <14978@ut-emx.UUCP> allred@ut-emx.UUCP (Kevin L. Allred) writes:
I'm putting together a low end workstation for my personal use at home.
It will have a 386SX, 4MB memory and monochrome VGA graphics.
Initially I plan to just run MSDOS, but soon I would like to run UNIX.
I currently am considering hard drives in the range of 65 to 80 MB. I
was only considering an RLL drive with 1:1 interleve controller until
I had pointed out to me that Segate has recently started marketing a
low cost SCSI addaptor (ST01 and ST02) suitable for use with its
ST296N 80MB hard disk. This combination reportedly offeres about 750
KB/sec transfer rate, which is comparable to the 1:1 interleve RLL
transfer rate, and it is more cost effective. Apparently the SCSI
addaptor works fine under DOS, but I have already had related to me
that it probably won't work with UNIX because of lack of drivers (I
heard that was a problem common to most SCSI boards even the expensive
intelligent ones like the WD7000). Are the various UNIX vendors
developing drivers, so that I don't need to worry about this, or
should I stick with the RLL controller and disks?
I have used a Priam 738 SCSI disk (337 MB, 20ms) with the Seagate
ST-01 controller for about one and a half years now. For the first
half an year I used it under msdos in a slow 16-MHz 386 machine.
Coretest and others reported transfer rates in the range of 750 KB/sec.
(Check that you have the 0WS jumper installed - without it I only got
something like 500 KB/sec).
About an year ago I purchased Microport Unix System V/386, and wrote
a device driver for the controller and the disk. I posted the driver
here about two weeks ago. The driver has been in use on my system and
a couple of other systems for over an year. The driver has proved to be
very reliable (some problems were reported with Seagate ST227N when
using 1KB sectors, but those disappeared by formatting the drive to
use 512 byte sectors). The driver supports multiple drives and partitions.
My disk is partitioned in three partitions: 10 MB /tmp, 20 MB /u2 and
307 MB /u. (BTW, I have never had any problems with large partitions.
Some people have reported problems in the news.)
I cannot give exact transfer rates under unix. With my original driver
I only got something like 160 KB/sec while reading a large (10-20 MB)
file with dd -bs 64k. That with an interleave of 9 and 1 KB sectors (sic!).
I have since optimized the data transfer routines by writing them
in assembly language. This should probably allow interleaves in the
range 1-3. I have not yet been able to test any other interleaves, as I have
not wanted to reformat the entire disk (it takes quite a while to copy
300 megabytes to floppies and back...) Note that when formatting the disk,
it can be helpful to explicitly specify that mkfs does no interleaving
on the file system level as that is already handled by the drive.
As a reference, measured the same way my 40ms 42MB MFM drive gives
40 kB/sec (sic!). I was not able to improve it from that.
The scsi disk was actually so much faster that I copied /bin and /usr/bin
to the scsi disk (/u/bin & /u/usr/bin) and put those in PATH before
/bin and /usr/bin. The difference is very significant.
The biggest problem with the driver is that during heavy disk activity
the serial lines lose incoming characters. But then I hear this is a
general problem with Microport...
BTW, my driver cannot be used to boot from the scsi disk. I use the
42 MB disk that came with the system for booting and swap (luckily I have
10 MB of ram, so the machine hardly ever swaps).
Tatu Ylonen ylo@sauna.hut.fiallred@ut-emx.UUCP (Kevin L. Allred) (07/11/89)
In article <14978@ut-emx.UUCP>, allred@ut-emx.UUCP (Kevin L. Allred) writes: > I had pointed out to me that Segate has recently started marketing a > low cost SCSI addaptor (ST01 and ST02) suitable for use with its > ST296N 80MB hard disk. This combination reportedly offeres about 750 > KB/sec transfer rate, which is comparable to the 1:1 interleve RLL My questions seem to have raised a bit of interest and varied reaction from several respondents. In brief the key points of the responces have been (focussing on the ST01 or ST02 rather than the ST296N): 1) Spintest and Coretest recorded transfer rates of about 450 KB/sec. 2) Spintest may not fairly report SCSI speeds (huh?). 3) BIOS can make a big difference -- >800 KB/sec for 3rd party BIOS. 4) Jumpering on the controller makes a difference (XT vs AT?) transfer rates jumped from 500KB/sec to 750KB/sec. 5) ST01 and ST02 do not support DMA transfers. Under Unix (DOS?) simultanious disk I/O with serial transfers can loose characters. Is anyone familiar enough with the ST0x controller to respond about the true capabilities of the ST0x controllers -- Seagate are you listening? If anyone can forward this on to some one there it would be appreciated. Item 5 in the list above is the current biggest concern to me. If the ST0x is not a DMA device what happens when I try to run software like zmodem downloads that want to do serial and disk I/O simultaneously? By the way, how can I get Spintest or Coretest? I would like to get a copy to benchmark whatever combination of disk and controller I end up buying? -- Kevin Allred allred@emx.cc.utexas.edu allred@ut-emx.UUCP
km@cadre.dsl.PITTSBURGH.EDU (Ken Mitchum) (07/11/89)
>Item 5 in the list above is the current biggest concern to me. If the >ST0x is not a DMA device what happens when I try to run software like >zmodem downloads that want to do serial and disk I/O simultaneously? The ST01 does support interrupts, so there is no need for the processor to "wait" for a transfer to take place. DMA was probably left off the card 1) to save money and 2) because there is no effective way in a DOS environment to take advantage of it. Ken Mitchum km@cadre.dsl.pitt.edu
paula@bcsaic.UUCP (Paul Allen) (07/11/89)
Is there anyone in the Pacific Northwest (or the West Coast, or... :-) who saved the Seagate ST-01 SCSI driver posted by ylo@sauna.hut.fi a couple of weeks ago? I'm considering buying a machine with this SCSI adaptor and could use an example driver as I create a driver for Minix. If you have the driver and can mail it to me, please drop me a note. On another note, I'm seeing reports (and rumors) placing the 'Coretest' transfer rate of systems using Seagate SCSI adaptors anywhere from 340 to 800 Kb/sec. Tatu Yl|nen reported that inserting the 'Ows' jumper raised the transfer rate from 500 to 700 Kb/sec. Anybody else have any stories to tell? Paul -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
Ralf.Brown@B.GP.CS.CMU.EDU (07/11/89)
In article <2966@cadre.dsl.PITTSBURGH.EDU>, km@cadre.dsl.PITTSBURGH.EDU (Ken Mitchum) writes: }>Item 5 in the list above is the current biggest concern to me. If the }>ST0x is not a DMA device what happens when I try to run software like }>zmodem downloads that want to do serial and disk I/O simultaneously? } }The ST01 does support interrupts, so there is no need for the processor }to "wait" for a transfer to take place. DMA was probably left off the }card 1) to save money and 2) because there is no effective way in a DOS }environment to take advantage of it. Another reason for leaving off the DMA is that DMA is a big lose on AT-class or 386 machines (at least as implemented by IBM PC compatibles--1 microsecond per transfer, as opposed to 400 ns on even a 10/0 AT using programmed I/O with the INSW and OUTSW instructions). In addition to being slower than INSW/OUTSW, DMA on a PC-compatible suffers from the problem of not being able to cross 64K boundaries, which INSW/OUTSW have no problems with (though they are, of course, limited to at most 64K at one time). With a true multitasking OS, however, even slow DMA would be better than programmed I/O, since another process can run while the transfer takes place. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 Disclaimer? I claimed something? "When things start going your way, it's usually because you stopped going the wrong way down a one-way street."
newman@inco.UUCP (Bo Newman) (07/11/89)
As to the Seagate SCSI Controler/Drives, I got one from Megahaus in TX for my Tandy 1000TL (48MB) and had problems with it "falling asleep" before it could complete a transfer of any size. I have been told that these controlers are not 100% *bus friendly* on all systems. I have since gone bask to more generic drives. Good Luck! =================================================================== :Bo Newman newman@inco.uu.net uunet!inco!newman : :McDonnell Douglas Electronics Systems Company (MDESC-WDC) : :McLean Virginia : :Voice Mail USA (202) 898-5564 (Answers as "The Newman Group") : :Fax USA (703) 883-3889 : ------------------------------------------------------------------- : ALL STANDARD DISCLAIMERS APPLY : ===================================================================
buck@siswat.UUCP (A. Lester Buck) (07/13/89)
In article <2966@cadre.dsl.PITTSBURGH.EDU>, km@cadre.dsl.PITTSBURGH.EDU (Ken Mitchum) writes: > >Item 5 in the list above is the current biggest concern to me. If the > >ST0x is not a DMA device what happens when I try to run software like > >zmodem downloads that want to do serial and disk I/O simultaneously? > > The ST01 does support interrupts, so there is no need for the processor > to "wait" for a transfer to take place. DMA was probably left off the > card 1) to save money and 2) because there is no effective way in a DOS > environment to take advantage of it. > > Ken Mitchum > km@cadre.dsl.pitt.edu The ST01 supports an interrupt on exactly one condition, the assertion of the SCSI SEL signal. For the ST01 this means it is being reselected to continue a transfer that the target (e.g., disk) previously suspended. [It also might mean that the ST01 is being selected as a target by another initiator, but the VLSI protocol chip on the ST01 does not support the inverse REQ/ACK sequence required for this mode.] But during a transfer, the ST01 definitely has a problem. It is designed to allow a REP MOVSB string move between the data buffer and the SCSI data port, for an efficient CPU transfer at full bus bandwidth. Unfortunately, the target runs everything in the transfer, and can change the SCSI bus phase from data in/out to anything, including bus free, whenever it likes. It will do this for unusual events like parity errors, or extremely common events like variable length tape records when the actual length is less than the requested length. Unless you are SURE that the bus phase will never change during the REP MOVSB (say, a block device with no errors), and thereby read some SCSI message and status bytes into a user buffer (or worse, time out and wake up in the bus free phase!), you need to monitor for bus phase changes before every byte, which severely limits the tranfser rate. The ST01 disk driver for Microport recently posted calls these the "fast" and "slow" modes, and it seems the "fast" mode is reasonably reliable for disks. The ST01 also violates the SCSI standard in a minor way that again will probably not ever show up in normal use. Basically, the ST01 is a terrifically cost effective SCSI host adapter for cheaper implementations. But you would be crazy to spend thousands on a fast, synchronous SCSI disk and hook it to a $50 asynchronous ST01 when only $250 more will get you an Adaptec 1542A with synchronous transfers and first party DMA. -- A. Lester Buck ...!texbell!moray!siswat!buck