how to maximize performance?

[Robert Dinse]

In article <1991Jun26.181856.5343 at watdragon.waterloo.edu>, sasingh at rose.waterloo.edu (I-I-Ice -now that's refreshing.) writes:
 > Could someone help me please?
 > 
 > I have been trying to figure out the best way to install 386ix and I am 
 > confused.
 > 
 > My system has an Adaptec 1542B, 4 megs of ram, with device 0 being the
 > ST296N (access time 28 ms) and device 1 the CDC (access time 18 ms).
 > 
 > I would like to put the Unix system itself on half of one of the drives (I
 > currently have 2 40 meg partitions on the 296N, and I would like to do the
 > same for the CDC), and put my user files on the other drive.
 > 
 > If I understand this correctly, then SCSI can send multi-threaded I/O
 > requests which can be processed by both devices simultaneously, rather than
 > all the I/O burden on one drive. As the cliche goes, two heads are better
 > than one.
 > 
 > But all this would be easy if the drives were the same, but they are not;
 > there are performance differences; and I do not know what portion of Unix
 > to put on which drive to guarantee best performance. Transfer rates for 
 > the two drives are:
 > 
 > 296N:	I/O Trans. Rate (Mbytes/sec)	1.5
 > 	Int. Trans. Rate (Mbits/sec)	10
 > 
 > CDC:    I/O Trans. Rate (Mbytes/sec)    1.25
 >         Int. Trans. Rate (Mbits/sec)    10
 > 
 > Finally, here is a transcript of a conversation with a friend of mine
 > about this.
 > 
 > Please reply to me privately, and if justified, I will re-post.
 > Thanks very much.
 > 
 > Ice.
 > 
 > -----------------------------------------
 > sasingh> Also question. Would it not make more sense to install Unix on
 > sasingh> the CDC Wren, since it has the faster mechanical access time?
 > sasingh> Unix is about 200 little programs, so a high transfer rate is
 > sasingh> not as important as finding the data quickly.
 > 
 > That would be true, but ...
 > 
 > sasingh> And swap space would be better utililized by the 296N since it
 > sasingh> has a slightly higher transfer rate than the CDC, but a slower
 > sasingh> access time; but since swap space is one big chunk, the slower
 > sasingh> seek time should not be a liability, since the head is usually
 > sasingh> going to be centered right at the beginning of the swap file
 > sasingh> right?
 > 
 > Well, actually, it depends on how they implement swap.  But, I'm pretty
 > sure that typically, the disk has to see back and forth to get to the
 > appropriate swap sector, and then read it.  You swap is big, right?  But
 > any swap block is relatively small.
 > 
 > As for Unix being lot's of small files, that is true.  But one small
 > file load will not matter much if you start swapping.  You'll notice a
 > significant speed decrease when you start swapping (as you could
 > probably guess) so optimizing that is more important.
 > 
 > As least that's how I'd do it.


     The process image in swap is contiguous, it is not scattered all over
in blocks like the file system files are.  Therefore, seek-time is relatively
unimportant for swap.  The files are contiguous in swap because speed is
critical.

     Another thing to consider is the number of disk buffers to allocate.
If you have too few, you will have a low hit rate for file system I/O and
poor performance, if you have the number to high, you won't have enough RAM
left over for user processes causing swap I/O to be high and reducing
performance.  There is an optimum point which is a compromise between
minimum file system physical I/O and swap I/O.  This point is entirely
dependant upon what you are doing with your machine and physical parameters
(how much RAM do you have, etc).

     If you plan to run B-news you will want to have a fairly large number
of disk buffers allocated otherwise your machine will do a large amount of
disk I/O for history searches for each article that comes in.

     If you do a ps -el and see the cumulative execution time getting large
on the swapper, it is a clue that you don't have enough user memory and
should either decrease the number of allocated buffers (or do something
else to make the kernal smaller) or get more RAM (or be prepared to suffer
poor performance).

     Your friend who suggested "swap blocks are small" might be thinking
about demand paging, where the system is able to page out individual
blocks instead of swapping the entire process.  Seek time would be an
important consideration for a paging area, but not for swap.