SCSI and 386/ix

[neese at adaptex.UUCP]

>   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