neese@adaptex.UUCP (02/01/90)
> I am considering using a Miniscribe 9380S as my primary drive > here at nstar - and would like to know if the difference in > throughput between the above drive running SCSI and a 18ms > RLLed drive running on a 2372B will be that noticeable. > >As to transfer rate, I don't think you will see much improvement. >After all it depends a lot on the encoding method on the drive >(hey, many Seagate SCSI drives are 4MHz!) You may get usually >10MHz instead of 7.5Mhz, but it's hardly noticeable. More importantly, if you are using XENIX, then the transfer rate will probably not improve much at all. XENIX does very small requests to the driver. On reads you may get up to 6K in a single command, but then virutally all reads are synchronously, that is the kernel will wait for each read to complete (per process) before starting another one. On writes, the kernel will buffer up until either update runs or it runs out of buufers for a request. In either case, writes are virtually all done in an asynchronous manner. Which means the kernel will dump a slew of write requests to the driver and then go on it's merry way. All writes are done 1K at a time. Although with the 1542A, it does releive the CPU from the chores of moving the data around and also minimizes the number of interrupts. This cannot be seen in the data transfer rate, but more in the overall loading of the system, which I think is more imporatant than the overall data rate. Think of it this way, it might take a little longer to load an application, but as more and more users login and start up apps, the time to load will virtually be the same for all the users, even if disk I/O is at an all time high. The way I have always stated this si, "Think of the 154xA adapter doing for disk I/O what a smart serial board does for serial I/O." >The real win is with *two* SCSI drives; while an RLL controller >usually is WD1003 compatible, and thus cannot possibly support >overlapped seeks or transfers, the ACB 1542 will support these, >and even scatter/gather. Both are *big* *big* wins, especially >on multiuser Unix systems. It may cost more, but getting two >drives (which is already a win with RLL, because at least you >have two independently positionable arms, even if you cannot run >them in parallel) instead of a single larger one can give >impressive reductions in terminal response times. This is absolutely correct. Under controlled conditions, the best that can be obtained with a ESDI/RLL/MFM controller and two disk drives is a 10%-15% increase in throughput. Under the same conditions, the 154xA adapter and 2 Quantum PRO drives will double the throughput. If a third drive is added, then the throughput triples and so on. Keep in mind that these are under controlled conditions, where all the disks were getting requests like so: req drv0, req drv1, req drv0... >It is extremely advisable to put root, usr and tmp on the first >drive, and swap and the home directories on the second drive, >otherwise load on the two drives will not be balanced, and you >lose much of the advantage. Splitting up the filesystem is always a matter of the application. If your system doesn't ever swap, then there is no gain to putting the swap on a second drive, but if it does swap, then this is absolutely true. I always like to put tmp on the second device, as that directory is constantly being used in my system. I put spool on its own partition on my root device to try to keep that dir from fragging my usr partition. I have my news/notes partition on the second drive and swap. Roy Neese Adaptec Central Field Applications Engineer UUCP @ {texbell,attctc}!cpe!adaptex!neese merch!adaptex!neese uunet!swbatl!texbell!merch!adaptex!neese
jlg@odicon.UUCP (John L. Grzesiak) (02/02/90)
In article <25c1fdd8:490comp.unix.i386@nstar.UUCP>, akcs.larry@nstar.UUCP (Larry Snyder) writes: > I am considering using a Miniscribe 9380S as my primary drive > here at nstar - and would like to know if the difference in > throughput between the above drive running SCSI and a 18ms > RLLed drive running on a 2372B will be that noticeable. > > I assume that 386/ix will support a SCSI host adapter with > a floppy drive adapter as a drop in replacement for the > 2372B (so I won't need a seperate controller for the floppy > drives). > > Comments? Ideas? Has anyone else gone this route? > > larry I do a bit of interactive R&D at work, here are a few numbers: 8 Mb transfer to null with : dd if=/dev/dsk/0s1 of=/dev/null bs=8k count=1024. RLL -wd1003 ESDI -wd1007vse2 SCSI -adaptec 1542A CDC-85 mb CDC-182 10mbps CDC-385H 3:1 interleave 1:1 interleave 1:1 interleave no track buffering track buffer cached Read Ahead Enabled raw 1:32.4 raw 12.2 raw 13.8 block 57.3 block 14.0 block 13.5 Notes: The track buffering on the WD1006vsr2 will be closer to the ESDI performance but will not boot or run ISC 2.0.1. or 2.0.2. The Adaptec ESDI (2322) was not much faster than the WD1003!! (About 32 seconds in block). Chantal was tested on the SCSI (ver 3.02 and 3.51) . It showed a minor decrease in raw and block transfer but an overall increase in loaded system performance. The SCSI figures are also slightly deceptive since the amount of system time required to do the transfer was less than half the WD interface controllers. The EDSI and RLL performance also decreases by a factor of two with dual drives. SCSI showed no such problem with two (or more) drives. Comments and conclusions. ESDI and RLL are still Programmed I/O type controllers requireing nearly full CPU attention, as well as being limited by the speed of the transfer rate. (i.e. a 10mbs ESDI setup with two drives will allow each drive to transfer about 5mbps). ESDI is limited to two controller on ISC (4 drives). With 4 Maxtor 768mb 15 mbps drives , maximum capacity is 2.4 gbytes formatted. SCSI is an 8megabyte transfer rate, DMA controller capable of transferring without processor intervention. Direct ISC support is two controllers and 4 drives (2.4 gbytes) or with 3rd party Chantal .. 3 controllers and many drives. Plus DAT tape support. My vote is SCSI..... just make sure you use Adaptecs controller and Enable read ahead on your drives. You will be super satified. *-----------------------------------------------------------------* * John Grzesiak @ Omega Dynamics : Specializing in UNIX/XENIX * * Meriden Ct USA : Consulting . . . * * jlg@odicon or spock!odicon!jlg : gaboon!odicon!jlg * *-----------------------------------------------------------------*
pcg@aber-cs.UUCP (Piercarlo Grandi) (02/02/90)
In article <25c77e8b:490.5comp.unix.i386;1@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: Me writes: >The real win is with *two* SCSI drives; while an RLL controller >usually is WD1003 compatible, and thus cannot possibly support >overlapped seeks or transfers, the ACB 1542 will support these, He observes: How about getting 2 2372B RLL controllers each controlling 1 drive? Wouldn't this have the same effect as two SCSI drives on the 1542? Yes, mostly. I have been considering doing this myself (I have a 2372B with two 60MB discs, and for expansion I have considered adding a second controller with another two discs). There are some problems though: * not all Unixes around support two controllers that easily, especially if they are the same type; * you don't get scatter-gather, which is a 1542 good idea (does anybody apart from ISC exloit that?); * you take up another backplane slot; * two WD1003 style controllers, for a total of four discs, is the maximum you can have, while SCSI is essentially unlimited (in theory); * if you want a tape, a SCSI controller that can drive all your peripherals is cheaper and takes many less slots. Also, I am not sure that the drivers that support two WD1003 compatible controllers do so in the right way, that is as independent entities, with independent sort queues, parallel operations, etc... If you have a spare 2372B lying around, by all means try adding it. I think that should make at least a noticeable difference. By the way, the 2372B is one of those few well designed controllers that have jumpers to enable/disable the BIOS, the floppies, and to relocate the IO ports; I am hard pressed to think of any other RLL controller (or MFM) that you can as easily configure as second controller. I will probably be switching to SCSI myself, because my main problem is backplane slots (I made the crucial mistake of getting a "baby AT" motherboard). -- 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
sl@van-bc.UUCP (Stuart Lynne) (02/03/90)
In article <288@odicon.UUCP> jlg@odicon.UUCP (John L. Grzesiak) writes: >In article <25c1fdd8:490comp.unix.i386@nstar.UUCP>, akcs.larry@nstar.UUCP (Larry Snyder) writes: }8 Mb transfer to null with : dd if=/dev/dsk/0s1 of=/dev/null bs=8k count=1024. } }RLL -wd1003 ESDI -wd1007vse2 SCSI -adaptec 1542A }CDC-85 mb CDC-182 10mbps CDC-385H }3:1 interleave 1:1 interleave 1:1 interleave }no track buffering track buffer cached Read Ahead Enabled } } raw 1:32.4 raw 12.2 raw 13.8 }block 57.3 block 14.0 block 13.5 } }Notes: } The track buffering on the WD1006vsr2 will be closer to the ESDI } performance but will not boot or run ISC 2.0.1. or 2.0.2. The Adaptec Works fine! Don't know why you can't get it to run. I didn't have any problems installing on an WD1006. raw: 17.0 block: 15.1 This is still the cheapest way to go for small systems. For either Xenix or UNIX. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
karl@ddsw1.MCS.COM (Karl Denninger) (02/04/90)
In article <25c77e8b:490.5comp.unix.i386;1@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >>The real win is with *two* SCSI drives; while an RLL controller >>usually is WD1003 compatible, and thus cannot possibly support >>overlapped seeks or transfers, the ACB 1542 will support these, > >How about getting 2 2372B RLL controllers each controlling 1 drive? >Wouldn't this have the same effect as two SCSI drives on the 1542? That actually does work quite well. Even with ONE controller, it's not bad. ISC >will< overlap seeks to the two devices, IF your controller can handle it. If not, you have to turn off that feature in the space.c file for the device (it's on by default); this is the cause of some problmes with certain revisions of the WD1006 boards. -- 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"
jlg@odicon.UUCP (John L. Grzesiak) (02/04/90)
In article <25c77e8b:490.5comp.unix.i386;1@nstar.UUCP>, larry@nstar.UUCP (Larry Snyder) writes: > >The real win is with *two* SCSI drives; while an RLL controller > >usually is WD1003 compatible, and thus cannot possibly support > >overlapped seeks or transfers, the ACB 1542 will support these, > > How about getting 2 2372B RLL controllers each controlling 1 drive? > Wouldn't this have the same effect as two SCSI drives on the 1542? In a word : no... While it would seem that this would allow a greater bandwidth thru the AT bus , they 1542A as a bus master is actually faster than two good ESDI controllers (Never mind RLL-st506). We won't go into how DMA controllers work , since there are several good books on the subject available. *-----------------------------------------------------------------* * John Grzesiak @ Omega Dynamics : Specializing in UNIX/XENIX * * Meriden Ct USA : Consulting . . . * * jlg@odicon or spock!odicon!jlg : gaboon!odicon!jlg * *-----------------------------------------------------------------*
greg@hpkslx.HP.COM (Greggory Orsini contractor) (02/06/90)
/ hpkslx:comp.unix.i386 / jlg@odicon.UUCP (John L. Grzesiak) / 8:25 pm Feb 1, 1990 / Notes: The track buffering on the WD1006vsr2 will be closer to the ESDI performance but will not boot or run ISC 2.0.1. or 2.0.2. ---------- Umm... I run (and boot) ISC 2.0.1 from a wd1006v-sr2 and xt2190 rll'ed drive. Just wanted to add some facts. Greg Orsini
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (02/06/90)
In article <1990Feb3.191842.1991@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes:
[ ... about having dual WD1003 style controllers ... ]
Even with ONE controller, it's not bad. ISC >will< overlap seeks to the two
devices, IF your controller can handle it. If not, you have to turn off
that feature in the space.c file for the device (it's on by default); this
is the cause of some problmes with certain revisions of the WD1006 boards.
This perplexes me. You sure that a WD1003 style controller can
overlap seeks? Are there any that do? I can hardly imagine seeks
not being synchronous to the controller with a WD1003 style
controller, that must issue step pulses to the head.
Are there really any RLL or MFM controllers (the WD1006 is by
your implication) that can step independently the two arms?
--
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.ukpcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (02/06/90)
In article <21600005@adaptex> neese@adaptex.UUCP writes:
Splitting up the filesystem is always a matter of the application. If your
system doesn't ever swap, then there is no gain to putting the swap on a
second drive,
Well, in most timesharing applications your system _should_ swap.
A very rough rule of thumb is that if a resource is less than 30%
used it is wasted (and if over 60% used it is insufficient, because
queues will form on a resource that is more than 60% committed on average).
Given that the majority of processes in a timesharing system is
inactive, and possibly for fiarly long times, swapping/paging is
healthy. If it does not occur, than you have too much memory for
your application mix. If you don't want it to occur because it is
too slow, this means that the swap bandwidth is undersized.
Tuning is the science/art where your major resources, CPU,
memory, IO bandwidth are all used more than 30%, and less than
60%. Well, actually you may overcommit a resource, if it is so
expensive that latency can be tolerated (the forming of queues).
but if it does swap, then this is absolutely true. I always
like to put tmp on the second device, as that directory is constantly being
used in my system. I put spool on its own partition on my root device to
try to keep that dir from fragging my usr partition. I have my news/notes
partition on the second drive and swap.
The logic between having tmp on a disc different from your user
homes is that virtually every compilation, editing, etc...
creates a copy of the file in /tmp, that is eventually copied
back to the user home. The same rationale applies to having the
swapping on a different disc from where the executables are; you
want to be able to be loading an executable while paging out
another.
There are some hidden assumptions here; for example, things are
slightly different if your compiler or editor are memory based,
or if your major application is not sw development.
You want to reduce the *instantaneous* load on a disc, not its average one;
and to avoid like taxes copies from a disc to the same disc.
--
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.ukjr@frog.UUCP (John Richardson) (02/06/90)
In article <1612@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > In article <25c77e8b:490.5comp.unix.i386;1@nstar.UUCP> > larry@nstar.UUCP (Larry Snyder) writes: > > Me writes: > > >The real win is with *two* SCSI drives; while an RLL controller > >usually is WD1003 compatible, and thus cannot possibly support > >overlapped seeks or transfers, the ACB 1542 will support these, > > He observes: > > How about getting 2 2372B RLL controllers each controlling 1 drive? > Wouldn't this have the same effect as two SCSI drives on the 1542? > > Yes, mostly. I have been considering doing this myself (I have > a 2372B with two 60MB discs, and for expansion I have > considered adding a second controller with another two discs). > > There are some problems though: > > * not all Unixes around support two controllers that easily, > especially if they are the same type; > The CPU moves the data on all WD1003 compatible controllers. It uses the INSW instruction. The AHA-1542 uses real master mode DMA to move the data without CPU intervention. > * you don't get scatter-gather, which is a 1542 good idea (does > anybody apart from ISC exloit that?); > It can if you write the driver to do so. Since the CPU moves the data, you have a programable scatter/gather mode if you do the code. JR
steve@nuchat.UUCP (Steve Nuchia) (02/06/90)
In article <PCG.90Feb5190711@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >This perplexes me. You sure that a WD1003 style controller can >overlap seeks? Are there any that do? I can hardly imagine seeks >not being synchronous to the controller with a WD1003 style >controller, that must issue step pulses to the head. Most high performance drives being sold today buffer the step pulses and optimize the head trajectory, so the controller could in theory diddle with the other drive while waiting for the ready indication. >Are there really any RLL or MFM controllers (the WD1006 is by >your implication) that can step independently the two arms? I've never seen any information on how to make any of them do it. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "If the conjecture `You would rather I had not disturbed you by sending you this.' is correct, you may add it to the list of uncomfortable truths." - Edsgar Dijkstra
karl@ddsw1.MCS.COM (Karl Denninger) (02/07/90)
In article <PCG.90Feb5190711@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <1990Feb3.191842.1991@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: > > [ ... about having dual WD1003 style controllers ... ] > > Even with ONE controller, it's not bad. ISC >will< overlap seeks to the two > devices, IF your controller can handle it. If not, you have to turn off > that feature in the space.c file for the device (it's on by default); this > is the cause of some problmes with certain revisions of the WD1006 boards. > >This perplexes me. You sure that a WD1003 style controller can >overlap seeks? Are there any that do? I can hardly imagine seeks >not being synchronous to the controller with a WD1003 style >controller, that must issue step pulses to the head. > >Are there really any RLL or MFM controllers (the WD1006 is by >your implication) that can step independently the two arms? Sure there are! Even the old WD1003 controllers can do this. MOST 1006's can. Some can't -- that is the cause of the mysterious "strange HD errors" with 2 drives under ISC. If you get those, have the controller swapped or make the change I posted a while back to the space.c file for the driver; it will go away. The boards do this using the buffered seek feature; they don't >really< overlap seeks per-se (since they only have one control channel that would be difficult!); what is done is the controller sends the seek pulses rapidly (far faster than the drive can complete them), then goes and does the other drive. When the drives reach their destination track(s) they report back seek complete, and the I/O operation (one at a time) actually takes place. This is one reason (among others) why ST412 drives are needed on an AT, rather than ST506. ST412 drives implement this buffered seek, while ST506 drives do not (that is pretty much the only difference between them; the ST412 drives also support > 8 heads, which some people find important :-). SCSI, on the other hand, can do even better. The Adaptec host adapter is faster than the drives; thus, it can (with a buffered drive) actually drive two disks at 2X the speed of one. With an ST412 controller you usually don't get better transfer rates (total) from two drives than one; with SCSI it happens all the time. -- 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"
campbell@redsox.bsw.com (Larry Campbell) (02/08/90)
In article <PCG.90Feb5190711@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes:
-This perplexes me. You sure that a WD1003 style controller can
-overlap seeks? Are there any that do? I can hardly imagine seeks
-not being synchronous to the controller with a WD1003 style
-controller, that must issue step pulses to the head.
-
-Are there really any RLL or MFM controllers (the WD1006 is by
-your implication) that can step independently the two arms?
Not exactly, but: most RLL/MFM drives are "buffered seek" drives. This
means that the step pulses do not have to be issued at a rate that matches
the physical movement of the head, but can be issued all at once (50 usec
apart, I seem to recall); the drive counts them and then steps the heads
itself. So I think you could fake overlapped seeks with such a drive.
--
Larry Campbell The Boston Software Works, Inc.
campbell@redsox.bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02109mark@promark.UUCP (Mark J. DeFilippis) (02/09/90)
In article <1612@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > > By the way, the 2372B is one of those few well designed > controllers that have jumpers to enable/disable the BIOS, the > floppies, and to relocate the IO ports; I am hard pressed to > think of any other RLL controller (or MFM) that you can as > easily configure as second controller. Used to be, and if you can find it. It seems in their infinite wisdom some dum dum at Adaptec decided the 2372B was not good enough or they decided to reduce construction costs, so it was changed. (A hypothesis). Now there is the the 2372C. The problem... well the alternate interrupt jumper is no longer present (They did leave edges D6 and D7 so at least you just have to hack the card and not your motherboard to pick up the alternate interrupt). And, no more disable floppy jumper. Now we are even harder pressed to find a MFM or RLL thats easily configured. On the positive side the alternate floppy address jumper is still there and just putting a jumper on here without the jumper for "disable floppy" seemed to create no interrupt conflict problems. (If it did you could just cut the interrupt trace anyway of course). Also the construction seems real real flimsy. The board flexes real easy and the bracket is as pliable as an aluminum can. As a matter of fact, the first controller the distributor sent me didn't even work, unheard of in the die-hard 2372B. I did call tech support to ask about the reason for the jumper removal, but it has only been two days so I havn't received my call back yet. They have limited support hours. -- Mark J. DeFilippis SA @ Department of Mathematics and Computer Science Adelphi University, Garden City, NY 11530 (516) 663-1170 UUCP: philabs!sbcs!bnlux0!adelphi!markd
pcg@aber-cs.UUCP (Piercarlo Grandi) (02/10/90)
In article <1535@redsox.bsw.com> campbell@redsox.UUCP (Larry Campbell) writes: In article <PCG.90Feb5190711@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: -Are there really any RLL or MFM controllers (the WD1006 is by -your implication) that can step independently the two arms? Not exactly, but: most RLL/MFM drives are "buffered seek" drives. This means that the step pulses do not have to be issued at a rate that matches the physical movement of the head, but can be issued all at once (50 usec apart, I seem to recall); the drive counts them and then steps the heads itself. So I think you could fake overlapped seeks with such a drive. Well, I have received by mail some information on how ISC does it. It is not just the buffering, which may well be there, but the problem of how do you know that the seek has actually been completed. This requires a trick. If you look back at a posting by an ISC guy in this thread the hint is there. It is really morbid overall, but does work (except on some 1006 controllers). What worries me quite a bit is news I have read in a recent 'Byte' issue that the WD1003 programmatic interface has been made into a standard, and given a suitably horrid acronym. Bah! -- 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