sasingh@rose.waterloo.edu (I-I-Ice -now that's refreshing.) (06/27/91)
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.nanook@eskimo.celestial.com (Robert Dinse) (06/29/91)
In article <1991Jun26.181856.5343@watdragon.waterloo.edu>, sasingh@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.
rlr@alumni.colorado.edu (Roger Rose) (06/30/91)
> 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. > ... > 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. The first statement is true for systems which swap, but my understanding is that even modern Sys-V's demand-page. (Most of my exposure is to BSD where even the paged space is fairly contiguous, since it's preallocated at process creation.) Assuming that I'm not mistaken that '386 ports of SVR3 (specifically 386ix) support demand-paging and only swap when they get starved for memory, don't they use the same "swap" area for paged and swapped memory? If so, then seek time is still important. There may be ways of minimizing the importance of seek time on paged systems. Overallocating the page space may help minimize fragmentation problems depending on what the page/swap activity looks like. Also, if the system supports multiple swap partitions and both the device-driver and virtual memory systems support overlapped I/O, then throughput can frequently be improved by allocating small swap partitions on each disk. Of course, the first thing to do is observe the virtual memory stats while the system is running. If you're not swapping and any significant paging activity is zero-fill or reclaiming stale pages, then there's little reason to be concerned about access to the swap area of the disk. -- Roger Rose {rlr@boulder.colorado.edu}