itkin@mrspoc.UUCP (Steven M. List) (04/08/89)
I'm trying to decide between ESDI and SCSI. I've heard a little of this
and a little of that without hearing anything that would really help me
make a decision. I've been considering the DPT caching ESDI controller.
Needless to say, as soon as I said so, someone told me I should REALLY
be considering SCSI. Can anyone out there educate me a bit?
Thanks.
--
: Steven List @ Transact Software, Inc. :^>~
: Chairman, Unify User Group of Northern California
: {apple,coherent,limbo,mips,pyramid,ubvax}!mrspoc!itkin
: Voice: (415) 961-6112vixie@decwrl.dec.com (Paul A Vixie) (04/08/89)
[Steven List] # I'm trying to decide between ESDI and SCSI. I've heard a little of this # and a little of that without hearing anything that would really help me # make a decision. I've been considering the DPT caching ESDI controller. # Needless to say, as soon as I said so, someone told me I should REALLY # be considering SCSI. Can anyone out there educate me a bit? Oboy. This is going to be a major flame fest, methinks. It always is. I have been extremely satisfied with ESDI. The drive does bad-sector maintainance -- allocating spares, keeping track of the bad ones, etc. With a 1:1 track-buffering DMA controller and the 386/ix file system implementation (SysV compatible media but better code in the kernel), I think I'm bus-speed limited. Since ESDI has good system management goodies and is fast enough to not be the weak link in the system, it's been my clear choice. Some of the nicer CDC drives are available with an ESDI interface, too. SCSI, on the other hand, is potentially faster in synchronous mode, now that decent SCSI controller chips are getting common. And ALL of CDC's big/fast drives are made available in SCSI before any other interface; with SCSI becoming more common, the prices of SCSI drives are a little bit more competitive than the prices of ESDI drives. I see no reason NOT to go with SCSI at this point, but it isn't enough better to get me to switch on future systems -- I'm too comfortable with the tools at hand. Eventually, the variance will get decisive. If you aren't committed already, and you can find a dealer or a consultant who will guarantee that the SCSI approach will work, jump in. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
usenet@cps3xx.UUCP (Usenet file owner) (04/10/89)
in article <6628@mrspoc.UUCP>, itkin@mrspoc.UUCP (Steven M. List) says: > Can anyone out there educate me a bit? I can't comment on ESDI vs SCSI. However, at work I have on my desk a 12.5 MHz 286 box using a 40MB Quantum SCSI drive with SCO XENIX 2.2.3. I am the only one hooked to the machine (w/ 4MB RAM). The through is just fine. One word of warning, since the kernel needs the SCSI driver installed, you have to gen a kernel on a machine with a normal AT drive and make a new N1 disk. I assume this is the same case for ESDI. I've always been under the impression that ESDI is faster than SCSI. Or is this a mistaken impression? I think I can safely say that SCSI is cheaper then ESDI. John H. Lawitzke UUCP: Work: ...rutgers!mailrus!frith!jhl Dale Computer Corp., R&D ...decvax!purdue!mailrus!frith!jhl 2367 Science Parkway ...uunet!frith!jhl Okemos, MI, 48864 Home: ...uunet!frith!ipecac!jhl
Dion_L_Johnson@cup.portal.com (04/11/89)
in article <mumble>, John Lawitzke writes:
[... deleted ... ]
One word of warning, since the kernel needs the SCSI
driver installed, you have to gen a kernel on a machine with a normal AT
drive and make a new N1 disk. I assume this is the same case for ESDI.
-----------
The new version of SCO XENIX named 2.3.2 GT is now available and
has SCSI, ESDI, and "ST-506" drivers all included.
- Dion L Johnsonwilliamt@athena1.Sun.COM (William A. Turnbow) (04/12/89)
Don't know if anyone had followed this up, but my experience with ESDI/SCSI drives leads me to believe that ESDI drives are faster. First off you have limiting factors in bus transfer speed. On an AT bus I believe this is something like around 4-5 Meg/sec. Neither of these drives comes close. The limiting factor from what I have seen is interleave, # sectors/track and (rarely) spin rate. The spin rate is almost always 3600 RPM or 60 RPS. Using this one can quickly see the maximum sustained xfer rate for a drive with 17 or 34 sectors per track (512 bytes/sec * # secs/trac * 60 RPS) = 522K/sec max for standard MFM and 1044K/sec max for standard ESDI. I haven't seen any standards on how many secs/track the SCSI drives have (in the small form factors), but the transfer rates were about 3/4 to '=' the ESDI's we evaluated. Also, SCSI controllers have *in the past* typically had about a 2-3 millisecond processing delay added on to commands because of the drives greater intelligence. The synchronous transfer rate for SCSI is meaningless if it can't get it off the disk. Of course if the SCSI controller has an on controller cache of some reasonable size, and perhaps a track read ahead then you might get better performance... -wat-
fyl@ssc.UUCP (Phil Hughes) (04/12/89)
In article <2422@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > I can't comment on ESDI vs SCSI. However, at work I have on my desk a > 12.5 MHz 286 box using a 40MB Quantum SCSI drive with SCO XENIX 2.2.3. > I am the only one hooked to the machine (w/ 4MB RAM). The through > is just fine. One word of warning, since the kernel needs the SCSI > driver installed, you have to gen a kernel on a machine with a normal AT > drive and make a new N1 disk. I assume this is the same case for ESDI. Most ESDI controllers are willing to look like a regular Western Digital interface to the AT bus. Therefore you can use the ST506 driver with an ESDI controller. SCSI, however, does require a different driver. SCO offers one - if you buy 386 XENIX you need 386-GT instead of 386-AT. I just found this out today. They seem a little confused internally about it as well. > I've always been under the impression that ESDI is faster than SCSI. Or > is this a mistaken impression? I think I can safely say that SCSI is > cheaper then ESDI. I am running ESDI drives on a 386 system running ENIX. It is fast. On the other hand I have a friend running SCSI drives on Rat Shit XENIX. It os probably faster. The reason is that the SCSI driver is smarter as is the SCSI controller. As for price, I found 100MB ESDI drives for $525 each. That is what I call cheap but the deal is long gone. The prices seem to be about equivalent. -- Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl
m5@lynx.uucp (Mike McNally) (04/12/89)
In article <98520@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: > Don't know if anyone had followed this up, but my experience with >ESDI/SCSI drives leads me to believe that ESDI drives are faster. > > First off you have limiting factors in bus transfer speed. On an >AT bus I believe this is something like around 4-5 Meg/sec. Try 0.5 Mbytes/sec, not 5. The DMA controller on the AT takes a long time getting on and off the bus. At least one company makes a SCSI controller for the AT that includes its own DMA controller that does burst transfers and thus runs closer to the speeds you mentioned. >Neither of >these drives comes close. The limiting factor from what I have seen is >interleave, # sectors/track and (rarely) spin rate. The spin rate is >almost always 3600 RPM or 60 RPS. Using this one can quickly see the >maximum sustained xfer rate for a drive with 17 or 34 sectors per track >(512 bytes/sec * # secs/trac * 60 RPS) = 522K/sec max for standard MFM >and 1044K/sec max for standard ESDI. The CDC Wren V drives we've used here can (with 64K requests) sustain about 1.2 Mbytes/sec. That's on a 20 Mhz. 386 AT. The ESDI drives with WD controllers only do about 600K/sec. Intelligent SCSI drives support a variable number of sectors per track, so one gets more out of the drive. They also do automatic bad block remapping. Many have integral RAM caches. Another big plus with SCSI is the ability to connect up to seven devices to one controller. Granted, this might be sort-of insane, but it can be done. One can go out and buy a SCSI cassette streamer for well under $1000 and backup 150meg of disk on one cassette. One can also get 9-track full size reel-to-reel SCSI drives for about $4000. -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go.
williamt@athena1.Sun.COM (William A. Turnbow) (04/13/89)
In article <5436@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >In article <98520@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: >> Don't know if anyone had followed this up, but my experience with >>ESDI/SCSI drives leads me to believe that ESDI drives are faster. >> >> First off you have limiting factors in bus transfer speed. On an >>AT bus I believe this is something like around 4-5 Meg/sec. > >Try 0.5 Mbytes/sec, not 5. The DMA controller on the AT takes a long >time getting on and off the bus. At least one company makes a SCSI >controller for the AT that includes its own DMA controller that does >burst transfers and thus runs closer to the speeds you mentioned. > >The CDC Wren V drives we've used here can (with 64K requests) sustain about >1.2 Mbytes/sec. That's on a 20 Mhz. 386 AT. The ESDI drives with WD >controllers only do about 600K/sec. Intelligent SCSI drives support a >variable number of sectors per track, so one gets more out of the drive. >They also do automatic bad block remapping. Many have integral RAM >caches. > >Mike McNally Lynx Real-Time Systems -- 1) I said bus transfer speed. Not DMA. I don't know if the DMA speed is different. 2) Can you explain how bot the ESDI and SCSI drives you mention (1.2M/s and .6M/s) are faster than the maximum DMA rate you claim? 3) Last time I looked at the AT bios it didn't use DMA in the disk routines. So it really isn't a factor. 4) You're right. The WD ESDI controller sucks. It seems to usually miss tracks and give a transfer rate closer to that of a 2:1 interleave drive than a 1:1. The Adaptek controller I have has been measured at slightly over 1M/s xfer rate raw, and over 800K/sec through DOS. 5) As for SCSI controllers supporting variable number of sectors per track, that is only in the interface presented to the user (computer). Since the SCSI controllers have intelligence in them, they can remap the physical sectors in whatever fashion they choose. This does not change the actual physical number of sectors/track, the spin rate, nor the final maximum transfer rate. We evaluated a couple SCSI drives at my last job, and several of them could present 63 sectors/track to the BIOS so that DOS could use disks that had > 1023 tracks (the BIOS doesn't support more than 1023 tracks or greater than 63 sectors/track). Presenting 63 sectors per track didn't physically change the media to allow greater sector packing. The transfer rate was the same as at the lower sectors per track (around 30 something...I believe). 6) Yes, it is useful to have the SCSI port if you have a need or use for it. But most people don't. I had a friend who gave that same argument, but because he had no SCSI devices to hook up, and because the SCSI drives were uniformly slower in seek time (around 2-3 ms) (xfer rate was about the same), and because the drives were uniformly more expensive, he went with an ESDI. At the time he was shopping, the SCSI drives were running about 33% more than equivalent capacity ESDI's. 7) Be careful about how you measure disk xfer speed. I have seen 'coretest' be totally fooled by one controller that kept an on board cache into believing it could xfer over 5Meg/sec on a 386. Some tests also seem to be less than reliable on ESDI drives because it is apparently common or standard to include a track buffer.
hjespers@vpk4.UUCP (Hans Jespersen) (04/14/89)
In article <5436@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >Another big plus with SCSI is the ability to connect up to seven devices >to one controller. Granted, this might be sort-of insane, but it can >be done. Not to mention that each of the seven devices can be SCSI<->ESDI bridge controllers, handling four ESDI drives. Thus one SCSI controller can handle 7 * 4 = 28 drives. At 300 MB per drive your looking at 8.4 GB of storage. I'm not even going to get into multiple SCSI controllers. Actually, the ability to attach seven devices isn't that insane. Consider three 300 MB disks, one 125 MB cartridge tape, one 6250 bpi 9 track streaming tape, and your left with only two taps for your Optical Disk and SCSI <-> MIDI interface. ;-) -- Hans Jespersen UUCP: uunet!attcan!hjespers AT&T Canada Inc. or ..!attcan!nebulus!arakis!hans Toronto, Ontario #include <std.disclaimer> "Yabba Dabba Doo" -- F. Flintstone
rickf@uts.amdahl.com (Rick Francis) (04/14/89)
In article <98520@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: > > Don't know if anyone had followed this up, but my experience with >ESDI/SCSI drives leads me to believe that ESDI drives are faster. > > First off you have limiting factors in bus transfer speed. On an >AT bus I believe this is something like around 4-5 Meg/sec. Neither of >these drives comes close. The limiting factor from what I have seen is >interleave, # sectors/track and (rarely) spin rate. The spin rate is >almost always 3600 RPM or 60 RPS. Using this one can quickly see the >maximum sustained xfer rate for a drive with 17 or 34 sectors per track >(512 bytes/sec * # secs/trac * 60 RPS) = 522K/sec max for standard MFM >and 1044K/sec max for standard ESDI. I haven't seen any standards on how >many secs/track the SCSI drives have (in the small form factors), but >the transfer rates were about 3/4 to '=' the ESDI's we evaluated. Also, SCSI >controllers have *in the past* typically had about a 2-3 millisecond >processing delay added on to commands because of the drives greater >intelligence. > > The synchronous transfer rate for SCSI is meaningless if it can't >get it off the disk. Of course if the SCSI controller has an on >controller cache of some reasonable size, and perhaps a track read >ahead then you might get better performance... > >-wat- ESDI probably is faster than SCSI for a _single_ drive. But since SCSI drives each have their own controller, a multiple drive SCSI system can have better overall throughput than a multiple drive/one controller ESDI system. The SCSI bus is capable of "dynamic reconnect." A host can issue a read request to one drive, disconnect from that drive and issue a request to other drives. When the first drive has read the requested sector, it can reconnect to the host and transfer the data at full SCSI-bus speed. This transfer is not limited by the rotational speed of the disk since the disk's controller already has the data in its buffer. The time required to process any given I/O request will be slower for SCSI because of the buffering of data in the controller, but the total number of requests processed per second can be much greater for SCSI than for ESDI. Of course it depends on how well the I/O load is distributed across the disks, and how well the driver is written. -- ======================================================== Rick Francis rickf@uts.amdahl.com Amdahl Corp. {decwrl,sun,uunet}!amdahl!rickf ======================================================== [Amdahl's opinions are expressed by Amdahl, not me.]
williamt@athena1.Sun.COM (William A. Turnbow) (04/14/89)
In article <18iMUeeCE3101061nHI@amdahl.uts.amdahl.com> rickf@amdahl.uts.amdahl.com (Rick Francis) writes: >for SCSI than for ESDI. Of course it depends on how well the I/O >load is distributed across the disks, and how well the driver is written. >======================================================== ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Rick Francis rickf@uts.amdahl.com ---- Do you know of any good scsi drivers for the 386 that would be usable for one of the Unix's? At the time I was shopping around, there were not even ANY SCSI drivers for microport or interactive (has this changed now?). -wat-
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (04/14/89)
In article <98994@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: >In article <18iMUeeCE3101061nHI@amdahl.uts.amdahl.com> rickf@amdahl.uts.amdahl.com (Rick Francis) writes: >>for SCSI than for ESDI. Of course it depends on how well the I/O >>load is distributed across the disks, and how well the driver is written. > Do you know of any good scsi drivers for the 386 that would be >usable for one of the Unix's? At the time I was shopping around, there >were not even ANY SCSI drivers for microport or interactive ... I am about to purchase a new 386AT machine, and I've been disturbed by this too. Unfortunately, you have to make this decision before you buy your hardware. I was considering Bell Tech's unix, but they do not have SCSI drivers. ENIX's literature says they have SCSI Hard disk drivers, but do not list any SCSI boards in their list of supported controllers. I plan on calling ENIX today to query them on this, and to call Bell Tech again to see if I can get some kind of cooperation on this subject. I will post a followup (I can't call yet, 1000EDT=0700PDT) when I have more info. Dan Daniel A. Graifer Franklin Capital Investments uunet!fciva!dag 7900 Westpark Drive, Suite A130 (703)821-3244 McLean, VA 22102
m5@lynx.uucp (Mike McNally) (04/14/89)
In article <98835@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: >1) I said bus transfer speed. Not DMA. I don't know if the DMA speed >is different. > >2) Can you explain how bot the ESDI and SCSI drives you mention (1.2M/s and >.6M/s) are faster than the maximum DMA rate you claim? I thought about that after I posted the note. The SCSI drive, of course, uses the interface I described which has its own DMA controller. The ESDI driver (which also does ST506) copies from the buffer on the controller. I stand corrected. (Of course, DMA is preferrable in a multi-tasking environment.) >5) As for SCSI controllers supporting variable number of sectors per track, >that is only in the interface presented to the user (computer). Since >the SCSI controllers have intelligence in them, they can remap the physical >sectors in whatever fashion they choose. This does not change the >actual physical number of sectors/track, the spin rate, nor the final >maximum transfer rate. This is not correct. The CDC Wren IV definitely varies the number of sectors per track across the disk. (I intuit that outer tracks have more sectors, but I haven't had any coffee yet so I could be wrong.) This is the big advantage of the drive over an ESDI drive: the Wren has an average of 45 sectors per track. Given a controller that can keep up (ours does), the Wren will of necessity show a higher transfer rate (not to mention the fact that the ESDI interface won't go faster than 10 megabits/sec, while asynchronous SCSI is 16 megabits/sec (the WD 33C93A SCSI chip actually does up to 2.5 megabytes/sec, which is 24 megabits/sec.)). >7) Be careful about how you measure disk xfer speed. I have seen 'coretest' >be totally fooled by one controller that kept an on board cache into believing >it could xfer over 5Meg/sec on a 386. Some tests also seem to be less >than reliable on ESDI drives because it is apparently common or standard >to include a track buffer. We're all well aware here of how bogus a lot of these figures can be. I think drive manufacturers get their transfer rates by issuing one command to read a contiguous megabyte and timing it. Although we do perform that test, we also test reading/writing to a regular file (in a UNIX-ish file system), reading/writing to a contiguous file (direct transfers from user memory to/from the disk), and reading/writing straight to the block or raw disk (the block view of the disk goes through the disk cache in the OS). Modern SCSI disks have very low command overhead, so this is not really an advantage of ESDI (with its own relatively complex command setup). Here's the beef: we can read from the Wren IV via SCSI at 1.4 megabytes per second, and write at just over a megabyte per second. ESDI drives don't go that fast. Of course, the Wren is rather expensive, but I can get 40 or 80 megabyte Quantum SCSI drives that are about as fast as fast as any ESDI disk on the block, and the Quantums are cheap (and small and very quiet). I can also plug in a SCSI TEAC streaming cartiridge drive and back up 150 megabytes on one cassette. Or, I can plug in my Qualstar reel-to-reel and read 1600 bpi GNU tapes. I should of course add that these arguments may not apply to all SCSI interfaces. Our SCSI controller uses a WD 31C93A controller chip at 10 Mhz (16 Mhz for faster systems, like 25Mhz 386 machines) and a bursting DMA controller. Your performance may vary. I really don't know much about other PC SCSI controllers. -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go.
jim@tiamat.fsc.com (Jim O'Connor) (04/15/89)
In article <4725@vpk4.UUCP>, hjespers@vpk4.UUCP (Hans Jespersen) writes: > > Actually, the ability to attach seven devices isn't that insane. > Consider three 300 MB disks, one 125 MB cartridge tape, one 6250 bpi > 9 track streaming tape, and your left with only two taps for > your Optical Disk and SCSI <-> MIDI interface. ;-) Don't forget the removeable cartridge hard drives that are available. I have a Syquest 44MB drive, and there is already a 100MB drive available. I've heard rumor of 150MB+ drives. With that kind of capacity, and reliability (no problem with any cartridge in 5 months of usage), these cartridge drives could be an alternative to (generally) much slower tape drives. But if you're going to put 300MB fixed drives on the bus, you'll need one of the 2.2G 8mm tape drives, which are also available with SCSI interfaces :-) ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
hznx@vax5.CIT.CORNELL.EDU (04/15/89)
In article <98994@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: > Do you know of any good scsi drivers for the 386 that would be >usable for one of the Unix's? At the time I was shopping around, there >were not even ANY SCSI drivers for microport or interactive (has this >changed now?). Talk to your controller vendor, not to your UNIX vendor. As of 3/18/89, at least Columbia Data Products, Inc (PO Box 2584, Alamonte Springs, FL 32714; support (407) 869-6700; BBS (407) 862-4724) had drivers for Western Digital's 7000-FASST SCSI controller. Microport, Interactive, Bell Tech, and XENIX drivers were all available for shipment. As an aside, the FASST and FASST2 are excellent controllers. Not too expensive, live up to their names. Dan Dulitz Don't get angry at my mailer -- I am my mailer.
rcd@ico.ISC.COM (Dick Dunn) (04/15/89)
In article <5436@lynx.UUCP>, m5@lynx.uucp (Mike McNally) writes: > In article <98520@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: > > First off you have limiting factors in bus transfer speed. On an > >AT bus I believe this is something like around 4-5 Meg/sec. > > Try 0.5 Mbytes/sec, not 5. The DMA controller on the AT takes a long > time getting on and off the bus... Keep trying. Turnbow said the AT bus, not the DMA controller. The bus is a whole lot faster than 0.5 Mb/s. Hard-disk transfers on AT-style machines are traditionally done with programmed I/O, NOT with DMA (even in the BIOS). The disk controllers have sector buffers, since they have to do the ECC before anything's ready anyway, so it's not like the PIO has to wait on a disk. The business of hand transfer off a disk is probably strange to a lot of people coming from big-machine backgrounds--it certainly was to me, escpecially when I found that the floppy *does* use DMA! But it's not really all that bad...I notice we're running ESDI 63-sector drives at 1:1. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...Never offend with style when you can offend with substance.
jim@tiamat.fsc.com (Jim O'Connor) (04/15/89)
In article <467@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer) writes: > In article <98994@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: > > Do you know of any good scsi drivers for the 386 that would be > >usable for one of the Unix's? At the time I was shopping around, there > >were not even ANY SCSI drivers for microport or interactive ... > > I plan on calling ENIX today to query them on this, and to call Bell Tech > again to see if I can get some kind of cooperation on this subject. I will > post a followup (I can't call yet, 1000EDT=0700PDT) when I have more info. Well, it's not exactly UNIX, but I have heard from several people at SCO that version 2.3GT is shipping in full product. 2.3GT has support (I've been told) for SCSI, ESDI, and ST-506 controllers, and combinations thereof. The SCSI drivers in 2.2.4 (written by SCO, distributed by Tandy. Let me know if that's not right, Roy) are very good, so if the extensions in 2.3GT that will allow up to seven devices are as good, 2.3GT should be great to have around. I believe 2.3GT is even supposed to let one SCSI adapter talk to up to 7 other SCSI adapters, each of which has 7 devices, for a total of 49 SCSI devices!!! Now that's exciting!!! ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
nvk@ddsw1.MCS.COM (Norman Kohn) (04/16/89)
In article <98994@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: > Do you know of any good scsi drivers for the 386 that would be >usable for one of the Unix's? A few weeks ago someone at uport told me that a SCSI driver was in beta test and asked me if I wanted a copy. Unfortunately, I wasn't ready for it and said so. I can't recall which controller they were testing with (I might have it written down somewhere). Mylex has a nifty SCSI board that sits on the 32-bit bus and, in principal, should be faster than anyone else as a result. They are working on unix drivers (using 386-ix as a testbed, but expecting that the resulting driver may work with other 386 unix's as well). The principal limit to such portability will be globals shared with other drivers. The clock driver is the most likely culprit. If system calls have been properly used, perhaps we uport sites can get a SCSI driver without being exposed to the dread floating point fault, etc. -- Norman Kohn | ...ddsw1!nvk!norman Chicago, Il. | days/ans svc: (312) 650-6840 | eves: (312) 373-0564
james@bigtex.cactus.org (James Van Artsdalen) (04/17/89)
In <98835@sun.Eng.Sun.COM>, williamt@sun.UUCP (William A. Turnbow) wrote: > 3) Last time I looked at the AT bios it didn't use DMA in the disk > routines. So it really isn't a factor. DMA isn't really an option. Many (most?) hard disk controllers don't even have the "fingers" on the card for the DMA lines. > 5) As for SCSI controllers supporting variable number of sectors per > track, that is only in the interface presented to the user (computer). I had expected that someone would build a controller to present a WD1010 interface to the CPU, but no one has. All of the IDE drives have user-definable geometry, so the technique is well known. What happens is that when the drive is initialized, the CPU sends the geometry the CPU wants to the WD1010 registers. The IDE drives looks at the resultant capacity and sees if it fits. If so, the IDE drive just translates each incoming request into the underlying geometry. The same could be done with SCSI except that the underlying geometry would be in linear blocks. This IDE remapping capability is why one needn't find exact drive-type entries in the BIOS for IDE drives (though you loose some space if you don't). All you do is find an entry with the same (or less) net capacity and just use it, without regard to the number of heads or sectors. The IDE drive will remap your choice into the real geometry. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" DCC Corporation 9505 Arboretum Blvd Austin TX 78759 512-338-8789
rcd@ico.ISC.COM (Dick Dunn) (04/19/89)
In article <15739@clover.ICO.ISC.COM>, I screwed up... > ...I notice we're running ESDI 63-sector drives at 1:1. 63 is the "logical" number of sectors, which is a game in the controller to get you around the 10-bit limit on number of cylinders. (They fake a higher number of heads and spt to get the cylinder count under 1024.) The disks are physically 34 spt. They still do run 1:1 and they are pretty fast, though. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...Never offend with style when you can offend with substance.
ts@cup.portal.com (Tim W Smith) (04/22/89)
Another thing to think about is SCSI-2. SCSI-2 will have several attractive features, such as a much higher data transfer rate, and more intelligence on the drives. For instance, SCSI-2 allows for command queueing in devices. When you send a device a queued command, the drive is allowed to place the command in a queue. There can be up to 256 commands queued. The drive can then execute these commands in an optimal ordering. SCSI-1 drives will work under SCSI-2, and SCSI-1 controllers will be able to work with SCSI-2 peripherals with only software changes, so if you chose SCSI-1 now, your peripheral will still work if you decide to upgrade to SCSI-2 later. With ESDI you may get stuck. The extra command overhead of SCSI vs. ESDI is going away. There are SCSI controller chips that will soon be available that should cut this down to the 200 to 300 microsecond range. Tim Smith
bakken@arizona.edu (Dave Bakken) (04/23/89)
In article <17478@cup.portal.com>, ts@cup.portal.com (Tim W Smith) writes: [ tells about SCSI-2] > The extra command overhead of SCSI vs. ESDI is going away. There > are SCSI controller chips that will soon be available that should > cut this down to the 200 to 300 microsecond range. > > Tim Smith When will SCSI-2 peripherals (esp HDs and controllers) be readily available? And how will their costs compare with SCSI-1 and ESDI? Thanks! -- Dave Bakken bakken@arizona.edu uunet!arizona!bakken "The fact that I'm paranoid doesn't prove everyone's *not* out to get me"