document distributed with 4.2BSD

SCCS-vsn: share/doc/papers/diskperf/abs.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/appendix.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/conclusions.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/equip.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/methodology.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/motivation.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/results.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/tests.ms 5.1
SCCS-vsn: share/doc/papers/diskperf/Makefile 5.1

diff --git a/usr/src/share/doc/papers/diskperf/Makefile b/usr/src/share/doc/papers/diskperf/Makefile
new file mode 100644 (file)
index 0000000..78a16cc
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/Makefile
@@ -0,0 +1,16 @@
+#
+# Copyright (c) 1983 Regents of the University of California.
+# All rights reserved.  The Berkeley software License Agreement
+# specifies the terms and conditions for redistribution.
+#
+#      @(#)Makefile    5.1 (Berkeley) %G%
+#
+TROFF= itroff
+FILES= abs.ms motivation.ms equip.ms methodology.ms tests.ms results.ms \
+       conclusions.ms appendix.ms
+
+paper: ${FILES}
+       @tbl ${FILES} | ${TROFF} -ms
+
+preview:${FILES}
+       tbl ${FILES} | nroff -ms | colcrt

diff --git a/usr/src/share/doc/papers/diskperf/abs.ms b/usr/src/share/doc/papers/diskperf/abs.ms
new file mode 100644 (file)
index 0000000..0d58a2f
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/abs.ms
@@ -0,0 +1,148 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)abs.ms      5.1 (Berkeley) %G%
+.\"
+.if n .ND
+.TL
+Performance Effects of Disk Subsystem Choices
+for VAX\(dg Systems Running 4.2BSD UNIX*
+.sp
+Revised July 27, 1983
+.AU
+Bob Kridle
+.AI
+mt Xinu
+2405 Fourth Street
+Berkeley, California  94710
+.AU
+Marshall Kirk McKusick\(dd
+.AI
+Computer Systems Research Group
+Computer Science Division
+Department of Electrical Engineering and Computer Science
+University of California, Berkeley
+Berkeley, CA  94720
+.AB
+.FS
+\(dgVAX, UNIBUS, and MASSBUS are trademarks of Digital Equipment Corporation.
+.FE
+.FS
+* UNIX is a trademark of Bell Laboratories.
+.FE
+.FS
+\(ddThis work was supported under grants from
+the National Science Foundation under grant MCS80-05144,
+and the Defense Advance Research Projects Agency (DoD) under
+Arpa Order No. 4031 monitored by Naval Electronic System Command under
+Contract No. N00039-82-C-0235.
+.FE
+Measurements were made of the UNIX file system
+throughput for various I/O operations using the most attractive currently
+available Winchester disks and controllers attached to both the
+native busses (SBI/CMI) and the UNIBUS on both VAX 11/780s and VAX 11/750s.
+The tests were designed to highlight the performance of single
+and dual drive subsystems operating in the 4.2BSD
+.I
+fast file system
+.R
+environment.
+Many of the results of the tests were initially counter-intuitive
+and revealed several important aspects of the VAX implementations
+which were surprising to us.
+.PP
+The hardware used included two  Fujitsu 2351A 
+``Eagle''
+disk drives on each of two foreign-vendor disk controllers
+and two DEC RA-81 disk drives on a DEC UDA-50 disk controller.
+The foreign-vendor controllers were Emulex SC750, SC780
+and Systems Industries 9900 native bus interfaced controllers.
+The DEC UDA-50 controller is a UNIBUS interfaced, heavily buffered
+controller which is the first implementation of a new DEC storage
+system architecture, DSA.
+.PP
+One of the most important results of our testing was the correction
+of several timing parameters in our device handler for devices
+with an RH750/RH780 type interface and having high burst transfer
+rates.
+The correction of these parameters resulted in an increase in
+performance of over twenty percent in some cases.
+In addition, one of the controller manufacturers altered their bus
+arbitration scheme to produce another increase in throughput.
+.AE
+.LP
+.de PT
+.lt \\n(LLu
+.pc %
+.nr PN \\n%
+.tl '\\*(LH'\\*(CH'\\*(RH'
+.lt \\n(.lu
+..
+.af PN i
+.ds LH Performance
+.ds RH Contents
+.bp 1
+.if t .ds CF July 27, 1983
+.if t .ds LF CSRG TR/8
+.if t .ds RF Kridle, et. al.
+.ce
+.B "TABLE OF CONTENTS"
+.LP
+.sp 1
+.nf
+.B "1.  Motivation"
+.LP
+.sp .5v
+.nf
+.B "2.  Equipment
+2.1.    DEC UDA50 disk controller
+2.2.    Emulex SC750/SC780 disk controllers
+2.3.    Systems Industries 9900 disk controller
+2.4.    DEC RA81 disk drives
+2.5.    Fujitsu 2351A disk drives
+.LP
+.sp .5v
+.nf
+.B "3.  Methodology
+.LP
+.sp .5v
+.nf
+.B "4.  Tests
+.LP
+.sp .5v
+.nf
+.B "5.  Results
+.LP
+.sp .5v
+.nf
+.B "6.  Conclusions
+.LP
+.sp .5v
+.nf
+.B Acknowledgements
+.LP
+.sp .5v
+.nf
+.B References
+.LP
+.sp .5v
+.nf
+.B "Appendix A
+A.1.     read_8192
+A.2.     write_4096
+A.3.     write_8192
+A.4.     rewrite_8192
+.ds RH Motivation
+.af PN 1
+.bp 1
+.de _d
+.if t .ta .6i 2.1i 2.6i
+.\" 2.94 went to 2.6, 3.64 to 3.30
+.if n .ta .84i 2.6i 3.30i
+..
+.de _f
+.if t .ta .5i 1.25i 2.5i
+.\" 3.5i went to 3.8i
+.if n .ta .7i 1.75i 3.8i
+..

diff --git a/usr/src/share/doc/papers/diskperf/appendix.ms b/usr/src/share/doc/papers/diskperf/appendix.ms
new file mode 100644 (file)
index 0000000..1b93346
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/appendix.ms
@@ -0,0 +1,71 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)appendix.ms 5.1 (Berkeley) %G%
+.\"
+.nr H2 1
+.ds RH Appendix A
+.SH
+\s+2Appendix A\s0
+.SH
+read_8192
+.DS
+#define        BUFSIZ 8192
+main( argc, argv)
+char **argv;
+{
+       char buf[BUFSIZ];
+       int i, j;
+
+       j = open(argv[1], 0);
+       for (i = 0; i < 1024; i++)
+               read(j, buf, BUFSIZ);
+}
+.DE
+.SH
+write_4096
+.DS
+#define        BUFSIZ 4096
+main( argc, argv)
+char **argv;
+{
+       char buf[BUFSIZ];
+       int i, j;
+
+       j = creat(argv[1], 0666);
+       for (i = 0; i < 2048; i++)
+               write(j, buf, BUFSIZ);
+}
+.DE
+.SH
+write_8192
+.DS
+#define        BUFSIZ 8192
+main( argc, argv)
+char **argv;
+{
+       char buf[BUFSIZ];
+       int i, j;
+
+       j = creat(argv[1], 0666);
+       for (i = 0; i < 1024; i++)
+               write(j, buf, BUFSIZ);
+}
+.DE
+.bp
+.SH
+rewrite_8192
+.DS
+#define        BUFSIZ 8192
+main( argc, argv)
+char **argv;
+{
+       char buf[BUFSIZ];
+       int i, j;
+
+       j = open(argv[1], 2);
+       for (i = 0; i < 1024; i++)
+               write(j, buf, BUFSIZ);
+}
+.DE

diff --git a/usr/src/share/doc/papers/diskperf/conclusions.ms b/usr/src/share/doc/papers/diskperf/conclusions.ms
new file mode 100644 (file)
index 0000000..5645612
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/conclusions.ms
@@ -0,0 +1,100 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)conclusions.ms      5.1 (Berkeley) %G%
+.\"
+.ds RH Conclusions
+.NH
+Conclusions
+.PP
+Peak available throughput is only one criterion
+in most storage system purchasing decisions.
+Most of the VAX UNIX systems we are familiar with
+are not I/O bandwidth constrained.
+Nevertheless, an adequate disk bandwidth is necessary for
+good performance and especially to preserve snappy
+response time.
+All of the disk systems we tested provide more than
+adequate bandwidth for typical VAX UNIX system application.
+Perhaps in some I/O-intensive applications such as
+image processing, more consideration should be given
+to the peak throughput available.
+In most situations, we feel that other factors are more
+important in making a storage choice between the systems we
+tested.
+Cost, reliability, availability, and support are some of these
+factors.
+The maturity of the technology purchased must also be weighed
+against the future value and expandability of newer technologies.
+.PP
+Two important conclusions about storage systems in general
+can be drawn from these tests.
+The first is that buffering can be effective in smoothing
+the the effects of lower bus speeds and bus contention.
+Even though the UDA50 is located on the relatively slow
+UNIBUS, its performance is similar to controllers located on
+the faster processor busses.
+However, the SC780 with only one sector of buffering shows that
+little buffering is needed if the underlying bus is fast enough.
+.PP
+Placing more intelligence in the controller seems to hinder UNIX system
+performance more than it helps.
+Our profiling tests have indicated that UNIX spends about
+the same percentage of time in the SC780 driver and the UDA50 driver
+(about 10-14%).
+Normally UNIX uses a disk sort algorithm that separates reads and
+writes into two seek order queues.
+The read queue has priority over the write queue,
+since reads cause processes to block,
+while writes can be done asynchronously.
+This is particularly useful when generating large files,
+as it allows the disk allocator to read
+new disk maps and begin doing new allocations
+while the blocks allocated out of the previous map are written to disk.
+Because the UDA50 handles all block ordering,
+and because it keeps all requests in a single queue,
+there is no way to force the longer seek needed to get the next disk map.
+This disfunction causes all the writes to be done before the disk map read,
+which idles the disk until a new set of blocks can be allocated.
+.PP
+The additional functionality of the UDA50 controller that allows it
+to transfer simultaneously from two drives at once tends to make
+the two drive transfer tests run much more effectively.
+Tuning for the single drive case works more effectively in the two
+drive case than when controllers that cannot handle simultaneous
+transfers are used.
+.ds RH Acknowledgements
+.nr H2 1
+.sp 2
+.SH
+\s+2Acknowledgements\s0
+.PP
+We thank Paul Massigilia and Bill Grace
+of Digital Equipment Corp for helping us run our
+disk tests on their UDA50/RA81.
+We also thank Rich Notari and Paul Ritkowski
+of Emulex for making their machines available
+to us to run our tests of the SC780/Eagles.
+Dan McKinster, then of Systems Industries,
+arranged to make their equipment available for the tests.
+We appreciate the time provided by Bob Gross, Joe Wolf, and
+Sam Leffler on their machines to refine our benchmarks.
+Finally we thank our sponsors,
+the National Science Foundation under grant MCS80-05144,
+and the Defense Advance Research Projects Agency (DoD) under
+Arpa Order No. 4031 monitored by Naval Electronic System Command under
+Contract No. N00039-82-C-0235.
+.ds RH References
+.nr H2 1
+.sp 2
+.SH
+\s+2References\s0
+.LP
+.IP [McKusick83] 20
+McKusick, M., Joy, W., Leffler, S., and Fabry, R.
+"A Fast File System for UNIX",
+University of California at Berkeley,
+Computer Systems Research Group Technical Report #7, 1982.
+.ds RH Appendix A
+.bp

diff --git a/usr/src/share/doc/papers/diskperf/equip.ms b/usr/src/share/doc/papers/diskperf/equip.ms
new file mode 100644 (file)
index 0000000..050a3e7
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/equip.ms
@@ -0,0 +1,150 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)equip.ms    5.1 (Berkeley) %G%
+.\"
+.ds RH Equipment
+.NH
+Equipment
+.PP
+Various combinations of the three manufacturers disk controllers,
+and two pairs of Winchester disk drives were tested on both
+VAX 11/780 and VAX 11/750 CPUs. The Emulex and Systems Industries
+disk controllers were interfaced to Fujitsu 2351A 
+``Eagle''
+404 Megabyte disk drives.
+The DEC UDA50 disk controller was interfaced to two DEC RA81 
+456 Megabyte Winchester disk drives.
+All three controllers were tested on the VAX 780 although
+only the Emulex and DEC controllers were benchmarked on the VAX 11/750.
+Systems Industries makes a VAX 11/750 CMI interface for
+their controller, but we did not have time to test this device.
+In addition, not all the storage systems were tested for
+two drive throughput.
+Each of the controllers and disk drives used in the benchmarks
+is described briefly below.
+.NH 2
+DEC UDA50 disk controller
+.PP
+This is a new controller design which is part of a larger, long range
+storage architecture referred to as
+``DSA''
+or \fBD\fRigital \fBS\fRtorage \fBA\fRrchetecture.
+An important aspect of DSA is migrating a large part
+of the storage management previously handled in the operating
+system to the storage system. Thus, the UDA50 is a much more
+intelligent controller than previous interfaces like the RH750 or
+RH780.
+The UDA50 handles all error correction.
+It also deals with most of the physical storage parameters.
+Typically, system software requests a logical block or
+sequence of blocks.
+The physical locations of these blocks, 
+their head, track, and cylinder indices,
+are determined by the controller.
+The UDA50 also orders disk requests to maximize throughput
+where possible, minimizing total seek and rotational delays.
+Where multiple drives are attached to a single controller,
+the UDA50 can interleave
+simultaneous
+data transfers from multiple drives.
+.PP
+The UDA50 is a UNIBUS implementation of a DSA controller.
+It contains 52 sectors of internal buffering to minimize
+the effects of a slow UNIBUS such as the one on the VAX-11/780.
+This buffering also minimizes the effects of contention with
+other UNIBUS peripherals.
+.NH 2
+Emulex SC750/SC780 disk controllers
+.PP
+These two models of the same controller interface to the CMI bus
+of a VAX 11/750 and the SBI bus of a 11/VAX 780, respectively.
+To the operating system, they emulate either an RH750 or
+and RH780.
+The controllers install in the
+MASSBUS
+locations in the CPU cabinets and operate from the
+VAX power suplies.
+They provide an
+``SMD''
+or \fBS\fRtorage \fBM\fRodule \fBD\fRrive
+interface to the disk drives.
+Although a large number of disk drives use this interface, we tested
+the controller exclusively connected to Fujitsu 2351A disks.
+.PP
+The controller ws first implemented for the VAX-11/750 as the SC750
+model several years ago. Although the SC780 was introduced more
+recently, both are stable products with no bugs known to us.
+.NH 2
+System Industries 9900 disk controller
+.PP
+This controller is an evolution of the S.I. 9400 first introduced 
+as a UNIBUS SMD interface.
+The 9900 has been enhanced to include an interface to the VAX 11/780 native
+bus, the SBI.
+It has also been upgraded to operate with higher data rate drives such
+as the Fujitsu 2351As we used in this test.
+The controller is contained in its own rack-mounted drawer with an integral
+power supply.
+The interface to the SMD is a four module set which mounts in a
+CPU cabinet slot normally occupied by an RH780.
+The SBI interface derives power from the VAX CPU cabinet power
+supplies.
+.NH 2
+DEC RA81 disk drives
+.PP
+The RA81 is a rack-mountable 456 Megabyte (formatted) Winchester
+disk drive manufactured by DEC.
+It includes a great deal of technology which is an integral part
+of the DEC \fBDSA\fR scheme.
+The novel technology includes a serial packet based communications
+protocol with the controller over a pair of mini-coaxial cables.
+The physical characteristics of the RA81 are shown in the
+table below:
+.DS
+.TS
+box,center;
+c s
+l l.
+DEC RA81 Disk Drive Characteristics
+_
+Peak Transfer Rate     2.2 Mbytes/sec.
+Rotational Speed       3,600 RPM
+Data Sectors/Track     51
+Logical Cylinders      1,248
+Logical Data Heads     14
+Data Capacity  456 Mbytes
+Minimum Seek Time      6 milliseconds
+Average Seek Time      28 milliseconds
+Maximum Seek Time      52 milliseconds
+.TE
+.DE
+.NH 2
+Fujitsu 2351A disk drives
+.PP
+The Fujitsu 2351A disk drive is a Winchester disk drive
+with an SMD controller interface.
+Fujitsu has developed a very good reputation for
+reliable storage products over the last several years.
+The 2351A has the following physical characteristics:
+.DS
+.TS
+box,center;
+c s
+l l.
+Fujitsu 2351A Disk Drive Characteristics
+_
+Peak Transfer Rate     1.859 Mbytes/sec.
+Rotational Speed       3,961 RPM
+Data Sectors/Track     48
+Cylinders      842
+Data Heads     20
+Data Capacity  404 Mbytes
+Minimum Seek Time      5 milliseconds
+Average Seek Time      18 milliseconds
+Maximum Seek Time      35 milliseconds
+.TE
+.DE
+.ds RH Methodology
+.bp

diff --git a/usr/src/share/doc/papers/diskperf/methodology.ms b/usr/src/share/doc/papers/diskperf/methodology.ms
new file mode 100644 (file)
index 0000000..f1d6686
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/methodology.ms
@@ -0,0 +1,84 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)methodology.ms      5.1 (Berkeley) %G%
+.\"
+.ds RH Methodology
+.NH
+Methodology
+.PP
+Our goal was to evaluate the performance of the target peripherals
+in an environment as much like our 4.2BSD UNIX systems as possible.
+There are two basic approaches to creating this kind of test environment.
+These might be termed the \fIindirect\fR and the \fIdirect\fR approach.
+The approach used by DEC in producing most of the performance data
+on the UDA50/RA81 system under VMS is what we term the indirect
+approach.
+We chose to use the direct approach.
+.PP
+The indirect approach used by DEC involves two steps.
+First, the environment in which performance is to be evaluated
+is parameterized.
+In this case, the disk I/O characteristics of VMS were measured
+as to the distribution of various sizes of accesses and the proportion
+of reads and writes.
+This parameterization of
+typical
+I/O activity was termed a
+``vax mix.''
+The second stage involves simulating this mixture of I/O activities
+with the devices to be tested and noting the total volume of transactions
+processed per unit time by each system.
+.PP
+The problems encountered with this indirect approach often
+have to do with the completeness and correctness of the parameterization
+of the context environment.
+For example, the 
+``vax mix''
+model constructed for DECs tests uses a random distribution of seeks
+to the blocks read or written.
+It is not likely that any real system produces a distribution
+of disk transfer locations which is truly random and does not
+exhibit strong locality characteristics.
+.PP
+The methodology chosen by us is direct
+in the sense that it uses the standard structured file system mechanism present
+in the 4.2BSD UNIX operating system to create the sequence of locations
+and sizes of reads and writes to the benchmarked equipment.
+We simply create, write, and read
+files as they would be by user's activities.
+The disk space allocation and disk cacheing mechanism built into
+UNIX is used to produce the actual device reads and writes as well
+as to determine their size and location on the disk.
+We measure and compare the rate at which these 
+.I
+user files
+.R
+can be written, rewritten, or read.
+.PP
+The advantage of this approach is the implicit accuracy in
+testing in the same environment in which the peripheral
+will be used.
+Although this system does not account for the I/O produced
+by some paging and swapping, in our memory rich environment
+these activities account for a relatively small portion
+of the total disk activity.
+.PP
+A more significant disadvantage to the direct approach
+is the occasional difficulty we have in accounting for our
+measured results.
+The apparently straight-forward activity of reading or writing a logical file
+on disk can produce a complex mixture of disk traffic.
+File I/O is supported by a file management system that
+buffers disk traffic through an internal cache,
+which allows writes to ba handled asynchronously.
+Reads must be done synchronously,
+however this restriction is moderated by the use of read-ahead.
+Small changes in the performance of the disk controller
+subsystem can result in large and unexpected
+changes in the file system performance,
+as it may change the characteristics of the memory contention
+experienced by the processor.
+.ds RH Tests
+.bp

diff --git a/usr/src/share/doc/papers/diskperf/motivation.ms b/usr/src/share/doc/papers/diskperf/motivation.ms
new file mode 100644 (file)
index 0000000..c1c4441
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/motivation.ms
@@ -0,0 +1,66 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)motivation.ms       5.1 (Berkeley) %G%
+.\"
+.ds RH Motivation
+.NH
+Motivation
+.PP
+These benchmarks were performed for several reasons.
+Foremost was our desire to obtain guideline to aid
+in choosing one the most expensive components of any
+VAX UNIX configuration, the disk storage system.
+The range of choices in this area has increased dramatically
+in the last year.
+DEC has become, with the introduction of the UDA50/RA81 system,
+cost competitive
+in the area of disk storage for the first time.
+Emulex's entry into the VAX 11/780 SBI controller
+field, the SC780, represented a important choice for us to examine, given
+our previous success with their VAX 11/750 SC750 controller and
+their UNIBUS controllers.
+The Fujitsu 2351A
+Winchester disk drive represents the lowest cost-per-byte disk storage
+known to us.
+In addition, Fujitsu's reputation for reliability was appealing.
+The many attractive aspects of these components justified a more
+careful examination of their performance aspects under UNIX.
+.PP
+In addition to the direct motivation of developing an effective
+choice of storage systems, we hoped to gain more insight into
+VAX UNIX file system and I/O performance in general.
+What generic characteristics of I/O subsystems are most
+important?
+How important is the location of the controller on the SBI/CMI versus
+the UNIBUS?
+Is extensive buffering in the controller essential or even important?
+How much can be gained by putting more of the storage system
+management and optimization function in the controller as
+DEC does with the UDA50?
+.PP
+We also wanted to resolve particular speculation about the value of
+storage system optimization by a controller in a UNIX
+environment.
+Is the access optimization as effective as that already provided
+by the existing 4.2BSD UNIX device handlers for traditional disks?
+VMS disk handlers do no seek optimization.
+This gives the UDA50 controller an advantage over other controllers
+under VMS which is not likely to be as important to UNIX.
+Are there penalties associated with greater intelligence in the controller?
+.PP
+A third and last reason for evaluating this equipment is comparable
+to the proverbial mountain climbers answer when asked why he climbs
+a particular mountain,
+``It was there.''
+In our case the equipment
+was there.
+We were lucky enough to assemble all the desired disks and controllers
+and get them installed on a temporarily idle VAX 11/780.
+This got us started collecting data.
+Although many of the tests were later rerun on a variety of other systems,
+this initial test bed was essential for working out the testing bugs
+and getting our feet wet.
+.ds RH Equipment
+.bp

diff --git a/usr/src/share/doc/papers/diskperf/results.ms b/usr/src/share/doc/papers/diskperf/results.ms
new file mode 100644 (file)
index 0000000..60bcb2d
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/results.ms
@@ -0,0 +1,310 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)results.ms  5.1 (Berkeley) %G%
+.\"
+.ds RH Results
+.NH
+Results
+.PP
+The following tables indicate the results of our
+test runs.
+Note that each table contains results for tests run
+on two varieties of 4.2BSD file systems.
+The first set of results is always for a file system
+with a basic blocking factor of eight Kilobytes and a
+fragment size of 1 Kilobyte. The second sets of measurements
+are for file systems with a four Kilobyte block size and a
+one Kilobyte fragment size.
+The values in parenthesis indicate the percentage of CPU
+time used by the test program.
+In the case of the two disk arm tests, 
+the value in parenthesis indicates the sum of the percentage
+of the test programs that were run.
+Entries of ``n. m.'' indicate this value was not measured.
+.DS
+.TS
+box,center;
+c s s s s
+c s s s s
+c s s s s
+l | l s | l s
+l | l s | l s
+l | l l | l l
+l | c c | c c.
+4.2BSD File Systems Tests - \fBVAX 11/750\fR
+=
+Logically Sequential Transfers
+from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   Emulex SC750/Eagle      UDA50/RA81
+
+       1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      490 (69%)       620 (96%)       310 (44%)       520 (65%)
+write_4096     380 (99%)       370 (99%)       370 (97%)       360 (98%)
+write_8192     470 (99%)       470 (99%)       320 (71%)       410 (83%)
+rewrite_8192   650 (99%)       620 (99%)       310 (50%)       450 (70%)
+=
+.T&
+c s s s s
+c s s s s
+l | l s | l s
+l | l s | l s
+l | l l | l l
+l | c c | c c.
+Logically Sequential Transfers
+from \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   Emulex SC750/Eagle      UDA50/RA81
+
+       1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      300 (60%)       400 (84%)       210 (42%)       340 (77%)
+write_4096     320 (98%)       320 (98%)       220 (67%)       290 (99%)
+write_8192     340 (98%)       340 (99%)       220 (65%)       310 (98%)
+rewrite_8192   450 (99%)       450 (98%)       230 (47%)       340 (78%)
+.TE
+.DE
+.PP
+Note that the rate of write operations on the VAX 11/750 are ultimately
+CPU limited in some cases.
+The write rates saturate the CPU at a lower bandwidth than the reads
+because they must do disk allocation in addition to moving the data
+from the user program to the disk.
+The UDA50/RA81 saturates the CPU at a lower transfer rate for a given
+operation than the SC750/Eagle because
+it causes more memory contention with the CPU.
+We do not know if this contention is caused by
+the UNIBUS controller or the UDA50.
+.PP
+The following table reports the results of test runs on a VAX 11/780
+with 4 Megabytes of main memory.
+.DS
+.TS
+box,center;
+c s s s s s s
+c s s s s s s
+c s s s s s s
+l | l s | l s | l s
+l | l s | l s | l s
+l | l l | l l | l l
+l | c c | c c | c c.
+4.2BSD File Systems Tests - \fBVAX 11/780\fR
+=
+Logically Sequential Transfers
+from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   Emulex SC780/Eagle      UDA50/RA81      Sys. Ind. 9900/Eagle
+
+       1 Drive 2 Drives        1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      560 (70%)       480 (58%)       360 (45%)       540 (72%)       340 (41%)       520 (66%)
+write_4096     440 (98%)       440 (98%)       380 (99%)       480 (96%)       490 (96%)       440 (84%)
+write_8192     490 (98%)       490 (98%)       220 (58%)*      480 (92%)       490 (80%)       430 (72%)
+rewrite_8192   760 (100%)      560 (72%)       220 (50%)*      180 (52%)*      490 (60%)       520 (62%)
+=
+.T&
+c s s s s s s
+c s s s s s s
+l | l s | l s | l s
+l | l s | l s | l s
+l | l l | l l | l l
+l | c c | c c | c c.
+Logically Sequential Transfers
+from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   Emulex SC780/Eagle      UDA50/RA81      Sys. Ind. 9900/Eagle
+
+       1 Drive 2 Drives        1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      490 (77%)       370 (66%)       n.m.    n.m.    200 (31%)       370 (56%)
+write_4096     380 (98%)       370 (98%)       n.m.    n.m.    200 (46%)       370 (88%)
+write_8192     380 (99%)       370 (97%)       n.m.    n.m.    200 (45%)       320 (76%)
+rewrite_8192   490 (87%)       350 (66%)       n.m.    n.m.    200 (31%)       300 (46%)
+.TE
+* the operation of the hardware was suspect during these tests.
+.DE
+.PP
+The dropoff in reading and writing rates for the two drive SC780/Eagle
+tests are probably due to the file system using insufficient
+rotational delay for these tests.
+We have not fully investigated these times.
+.PP
+The following table compares data rates on VAX 11/750s directly
+with those of VAX 11/780s using the UDA50/RA81 storage system.
+.DS
+.TS
+box,center;
+c s s s s
+c s s s s
+c s s s s
+l | l s | l s
+l | l s | l s
+l | l l | l l
+l | c c | c c.
+4.2BSD File Systems Tests - \fBDEC UDA50 - 750 vs. 780\fR
+=
+Logically Sequential Transfers
+from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   VAX 11/750 UNIBUS       VAX 11/780 UNIBUS
+
+       1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      310 (44%)       520 (84%)       360 (45%)       540 (72%)
+write_4096     370 (97%)       360 (100%)      380 (99%)       480 (96%)
+write_8192     320 (71%)       410 (96%)       220 (58%)*      480 (92%)
+rewrite_8192   310 (50%)       450 (80%)       220 (50%)*      180 (52%)*
+=
+.T&
+c s s s s
+c s s s s
+l | l s | l s
+l | l s | l s
+l | l l | l l
+l | c c | c c.
+Logically Sequential Transfers
+from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   VAX 11/750 UNIBUS       VAX 11/780 UNIBUS
+
+       1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      210 (42%)       342 (77%)       n.m.    n.m.
+write_4096     215 (67%)       294 (99%)       n.m.    n.m.
+write_8192     215 (65%)       305 (98%)       n.m.    n.m.
+rewrite_8192   227 (47%)       336 (78%)       n.m.    n.m.
+.TE
+* the operation of the hardware was suspect during these tests.
+.DE
+.PP
+The higher throughput available on VAX 11/780s is due to a number
+of factors.
+The larger main memory size allows a larger file system cache.
+The block allocation routines run faster, raising the upper limit
+on the data rates in writing new files.
+.PP
+The next table makes the same comparison using an Emulex controller
+on both systems.
+.DS
+.TS
+box, center;
+c s s s s
+c s s s s
+c s s s s
+l | l s | l s
+l | l s | l s
+l | l l | l l
+l | c c | c c.
+4.2BSD File Systems Tests - \fBEmulex - 750 vs. 780\fR
+=
+Logically Sequential Transfers
+from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   VAX 11/750 CMI Bus      VAX 11/780 SBI Bus
+
+       1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      490 (69%)       620 (96%)       560 (70%)       480 (58%)
+write_4096     380 (99%)       370 (99%)       440 (98%)       440 (98%)
+write_8192     470 (99%)       470 (99%)       490 (98%)       490 (98%)
+rewrite_8192   650 (99%)       620 (99%)       760 (100%)      560 (72%)
+=
+.T&
+c s s s s
+c s s s s
+l | l s | l s
+l | l s | l s
+l | l l | l l
+l | c c | c c.
+Logically Sequential Transfers
+from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   VAX 11/750 CMI Bus      VAX 11/780 SBI Bus
+
+       1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      300 (60%)       400 (84%)       490 (77%)       370 (66%)
+write_4096     320 (98%)       320 (98%)       380 (98%)       370 (98%)
+write_8192     340 (98%)       340 (99%)       380 (99%)       370 (97%)
+rewrite_8192   450 (99%)       450 (98%)       490 (87%)       350 (66%)
+.TE
+.DE
+.PP
+The following table illustrates the evolution of our testing
+process as both hardware and software problems effecting
+the performance of the Emulex SC780 were corrected.
+The software change was suggested to us by George Goble
+of Purdue University.
+.PP
+The 4.2BSD handler for RH750/RH780 interfaced disk drives
+contains several constants which to determine how
+much time is provided between an interrupt signaling the completion
+of a positioning command and the subsequent start of a data transfer
+operation. These lead times are expressed as sectors of rotational delay.
+If they are too small, an extra complete rotation will often be required
+between a seek and subsequent read or write operation.
+The higher bit rate and rotational speed of the 2351A Fujitsu
+disk drives required
+increasing these constants.
+.PP
+The hardware change involved allowing for slightly longer
+delays in arbitrating for cycles on the SBI bus by 
+starting the bus arbitration cycle a little further ahead of
+when the data was ready for transfer.
+Finally we had to increase the rotational delay between consecutive
+blocks in the file because
+the higher bandwidth from the disk generated more memory contention,
+which slowed down the processor.
+.DS
+.TS
+box,center,expand;
+c s s s s s s
+c s s s s s s
+c s s s s s s
+l | l s | l s | l s
+l | l s | l s | l s
+l | l s | l s | l s
+l | c c | c c | c c
+l | c c | c c | c c.
+4.2BSD File Systems Tests - \fBEmulex SC780 Disk Controller Evolution\fR
+=
+Logically Sequential Transfers
+from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   Inadequate Search Lead  OK Search Lead  OK Search Lead
+       Initial SBI Arbitration Init SBI Arb.   Improved SBI Arb.       
+
+       1 Drive 2 Drives        1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      320     370     440 (60%)       n.m.    560 (70%)       480 (58%)
+write_4096     250     270     300 (63%)       n.m.    440 (98%)       440 (98%)
+write_8192     250     280     340 (60%)       n.m.    490 (98%)       490 (98%)
+rewrite_8192   250     290     380 (48%)       n.m.    760 (100%)      560 (72%)
+=
+.T&
+c s s s s s s
+c s s s s s s
+l | l s | l s | l s
+l | l s | l s | l s
+l | l s | l s | l s
+l | c c | c c | c c
+l | c c | c c | c c.
+Logically Sequential Transfers
+from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
+_
+Test   Inadequate Search Lead  OK Search Lead  OK Search Lead
+       Initial SBI Arbitration Init SBI Arb.   Improved SBI Arb.       
+
+       1 Drive 2 Drives        1 Drive 2 Drives        1 Drive 2 Drives
+_
+read_8192      200     220     280     n.m.    490 (77%)       370 (66%)
+write_4096     180     190     300     n.m.    380 (98%)       370 (98%)
+write_8192     180     200     320     n.m.    380 (99%)       370 (97%)
+rewrite_8192   190     200     340     n.m.    490 (87%)       350 (66%)
+.TE
+.DE
+.ds RH Conclusions
+.bp

diff --git a/usr/src/share/doc/papers/diskperf/tests.ms b/usr/src/share/doc/papers/diskperf/tests.ms
new file mode 100644 (file)
index 0000000..3eea00e
--- /dev/null
+++ b/usr/src/share/doc/papers/diskperf/tests.ms
@@ -0,0 +1,81 @@
+.\" Copyright (c) 1983 Regents of the University of California.
+.\" All rights reserved.  The Berkeley software License Agreement
+.\" specifies the terms and conditions for redistribution.
+.\"
+.\"    @(#)tests.ms    5.1 (Berkeley) %G%
+.\"
+.ds RH Tests
+.NH
+Tests
+.PP
+Our battery of tests consists of four programs,
+read_8192, write_8192, write_4096
+and rewrite_8192 originally written by [McKusick83]
+to evaluate the performance of the new file system in 4.2BSD.
+These programs all follow the the same model and are typified by
+read_8192 shown here.
+.DS
+#define        BUFSIZ 8192
+main( argc, argv)
+char **argv;
+{
+       char buf[BUFSIZ];
+       int i, j;
+
+       j = open(argv[1], 0);
+       for (i = 0; i < 1024; i++)
+               read(j, buf, BUFSIZ);
+}
+.DE
+The remaining programs are included in appendix A.
+.PP
+These programs read, write with two different blocking factors,
+and rewrite logical files in structured file system on the disk
+under test.
+The write programs create new files while the rewrite program
+overwrites an existing file.
+Each of these programs represents an important segment of the
+typical UNIX file system activity with the read program
+representing by far the largest class and the rewrite the smallest.
+.PP
+A blocking factor of 8192 is used by all programs except write_4096.
+This is typical of most 4.2BSD user programs since a standard set of
+I/O support routines is commonly used and these routines buffer
+data in similar block sizes.
+.PP
+For each test run, a empty eight Kilobyte block
+file system was created in the target
+storage system.
+Then each of the four tests was run and timed.
+Each test was run three times;
+the first to clear out any useful data in the cache,
+and the second two to insure that the experiment
+had stablized and was repeatable.
+Each test operated on eight Megabytes of data to 
+insure that the cache did not overly influence the results.
+Another file system was then initialized using a 
+basic blocking factor of four Kilobytes and the same tests
+were run again and timed.
+A command script for a run appears as follows:
+.DS
+#!/bin/csh
+set time=2
+echo "8K/1K file system"
+newfs /dev/rhp0g eagle
+mount /dev/hp0g /mnt0
+mkdir /mnt0/foo
+echo "write_8192 /mnt0/foo/tst2"
+rm -f /mnt0/foo/tst2
+write_8192 /mnt0/foo/tst2
+rm -f /mnt0/foo/tst2
+write_8192 /mnt0/foo/tst2
+rm -f /mnt0/foo/tst2
+write_8192 /mnt0/foo/tst2
+echo "read_8192 /mnt0/foo/tst2"
+read_8192 /mnt0/foo/tst2
+read_8192 /mnt0/foo/tst2
+read_8192 /mnt0/foo/tst2
+umount /dev/hp0g
+.DE
+.ds RH Results
+.bp