share/doc/papers/diskperf/methodology.ms

   1 .\" Copyright (c) 1983 The Regents of the University of California.
   2 .\" All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. All advertising materials mentioning features or use of this software
  13 .\"    must display the following acknowledgement:
  14 .\"     This product includes software developed by the University of
  15 .\"     California, Berkeley and its contributors.
  16 .\" 4. Neither the name of the University nor the names of its contributors
  17 .\"    may be used to endorse or promote products derived from this software
  18 .\"    without specific prior written permission.
  19 .\"
  20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  23 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  30 .\" SUCH DAMAGE.
  31 .\"
  32 .\"     @(#)methodology.ms      6.2 (Berkeley) 4/16/91
  33 .\"
  34 .ds RH Methodology
  35 .NH
  36 Methodology
  37 .PP
  38 Our goal was to evaluate the performance of the target peripherals
  39 in an environment as much like our 4.2BSD UNIX systems as possible.
  40 There are two basic approaches to creating this kind of test environment.
  41 These might be termed the \fIindirect\fR and the \fIdirect\fR approach.
  42 The approach used by DEC in producing most of the performance data
  43 on the UDA50/RA81 system under VMS is what we term the indirect
  44 approach.
  45 We chose to use the direct approach.
  46 .PP
  47 The indirect approach used by DEC involves two steps.
  48 First, the environment in which performance is to be evaluated
  49 is parameterized.
  50 In this case, the disk I/O characteristics of VMS were measured
  51 as to the distribution of various sizes of accesses and the proportion
  52 of reads and writes.
  53 This parameterization of
  54 typical
  55 I/O activity was termed a
  56 ``vax mix.''
  57 The second stage involves simulating this mixture of I/O activities
  58 with the devices to be tested and noting the total volume of transactions
  59 processed per unit time by each system.
  60 .PP
  61 The problems encountered with this indirect approach often
  62 have to do with the completeness and correctness of the parameterization
  63 of the context environment.
  64 For example, the
  65 ``vax mix''
  66 model constructed for DECs tests uses a random distribution of seeks
  67 to the blocks read or written.
  68 It is not likely that any real system produces a distribution
  69 of disk transfer locations which is truly random and does not
  70 exhibit strong locality characteristics.
  71 .PP
  72 The methodology chosen by us is direct
  73 in the sense that it uses the standard structured file system mechanism present
  74 in the 4.2BSD UNIX operating system to create the sequence of locations
  75 and sizes of reads and writes to the benchmarked equipment.
  76 We simply create, write, and read
  77 files as they would be by user's activities.
  78 The disk space allocation and disk cacheing mechanism built into
  79 UNIX is used to produce the actual device reads and writes as well
  80 as to determine their size and location on the disk.
  81 We measure and compare the rate at which these
  82 .I
  83 user files
  84 .R
  85 can be written, rewritten, or read.
  86 .PP
  87 The advantage of this approach is the implicit accuracy in
  88 testing in the same environment in which the peripheral
  89 will be used.
  90 Although this system does not account for the I/O produced
  91 by some paging and swapping, in our memory rich environment
  92 these activities account for a relatively small portion
  93 of the total disk activity.
  94 .PP
  95 A more significant disadvantage to the direct approach
  96 is the occasional difficulty we have in accounting for our
  97 measured results.
  98 The apparently straight-forward activity of reading or writing a logical file
  99 on disk can produce a complex mixture of disk traffic.
 100 File I/O is supported by a file management system that
 101 buffers disk traffic through an internal cache,
 102 which allows writes to ba handled asynchronously.
 103 Reads must be done synchronously,
 104 however this restriction is moderated by the use of read-ahead.
 105 Small changes in the performance of the disk controller
 106 subsystem can result in large and unexpected
 107 changes in the file system performance,
 108 as it may change the characteristics of the memory contention
 109 experienced by the processor.
 110 .ds RH Tests
 111 .bp