BHraHRHfi DBVDQOuOi I -I IH- HI Ac ffBMIIBJWWQWBfll LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAfGN 510.84 ue&r no. 824-823 cop. X L16X _O-1096 +J /c ■ " ' Report No. UIUCDCS-R-76-826 NSF-0CA-DCR73-07980 A02-000023 AN ANALYSIS OF ROTATIONAL STORAGE ACCESS SCHEDULING IN A MULTIPROGRAMMED INFORMATION RETRIEVAL SYSTEM 6 by James Michael Milner September 1976 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS University °' " rf i8no-Chamoaign Digitized by the Internet Archive in 2013 http://archive.org/details/analysisofrotati826miln Report No. UIUCDCS-R-76-826 AN ANALYSIS OF ROTATIONAL STORAGE ACCESS SCHEDULING IN A MULTIPROGRAMMED INFORMATION RETRIEVAL SYSTEM* by James Michael Milner September 1976 Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 * This work was supported in part by the National Science Foundation under Grant No. US NSF-DCR73-07980 A02 and was submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science, September 1976. AN ANALYSIS OF ROTATIONAL STORAGE ACCESS SCHEDULING IN A MULTIPROGRAMMED INFORMATION RETRIEVAL SYSTEM James Michael Milner, Ph.D. Department of Computer Science University of Illinois at Urbana-Champaign , 1976 In this thesis the effects of five secondary storage access scheduling policies are studied in the context of a multiprogrammed information retrieval system. Such systems are characterized by independent requests for groups of records from the disk or drum secondary storage device. Further processing of each request is blocked until all records of the group, which we term a bulk, are accessed. A model which captures the essential behavior of the class of systems under study is described. Important parameters of the model are determined from a study of an actual system, MEDLINE. The behavior of the model under each of the five scheduling policies is studied both analytically and via simulation. Results show unexpectedly poor performance by the commonly used SCAN scheduling policy. Better scheduling policies are defined and features which characterize good and bad policies are enumerated. Details of the MEDLINE study and the simulator are included in appendixes along with an atlas of simulation results. Ill Dedicated to my wife Palma IV ACKNOWLEDGEMENTS The author wishes to express his gratitude to his thesis and academic adviser. Professor Jane W. S. Liu, for her guidance. My former academic adviser, Professor C. L. Liu, provided much appreciated wise counselling during my first year here. The other members of the Committee, Professors David J. Kuck, Duncan H. Lawrie, and H. George Friedman, contributed to making my graduate studies a valuable learning experience. The Department of Computer Science and the National Science Foundation provided financial support throughout. This work is a tribute to the constant support and unfaltering faith of my wife, Palma- Without her efforts this thesis would never have been written. TABLE OF CONTENTS Chapter Page 1 INTRODUCTION 1 2 THE MODEL 4 3 SIMULATION STUDIES 2U t| ANALYTICAL STUDIES 76 5 REVIEW, CONCLUSIONS, AND SUGGESTIONS 108 FOR FUTURE RESEARCH LIST OF REFERENCES 115 APPENDIX A - MEDLINE STUDY 118 APPENDIX B - DISK/DRUM SIMULATOR 149 APPENDIX C - ALGORITHM COMPARISONS 162 VITA 189 VI LIST OP TABLES Table Page 3.1a Request Service Time for 2314 Type Disk ...... 37 3.1b Balk Service Time for 2314 Type Disk . 37 3.1c Core Occupancy for 2314 Type Disk . . .37 3.2a Sample Algorithm Precedence Matrix for Mean of . . .59 Request Service Time 3.2b Sample Algorithm Precedence Matrix for Mean of ... 60 Bulk Service Time 3.2c Sample Algorithm Precedence Matrix for Mean of . . .61 Core Usage 3. 3a Drum Performance Comparisons as a Function of 6 - - 62 3.3b Disk Performance Comparisons as a Punction of 6 . . 63 3.4a Drum Performance Comparisons as a Punction of g . . 64 3.4b Disk Performance Comparisons as a Punction of g . . 65 3.5a Drum Performance Comparisons as a Function of i . . 66 3.5b Disk Performance Comparisons as a Function of i . . 67 4. 1 Differences of Random Cylinder Addresses ...... 93 4.2 MSCAN Latency Approximation ......97 A. 1 MEDLINE Tape Format 120 A. 2 MEDLINE System Statistics 123 A. 3 MEDLINE Oser Statistics 123 A. 4 MEDLINE Query Statistics - 123 A. 5 Term Osage in Queries ....... ....... .124 A. 6 Percent Usage of Terms in Queries . 124 A. 7 Connective Usage in Queries ........... .124 A. 8 Percent Usage of Connectives in Queries ..... .124 A. 9 Term Type Usage Distribution ........... .125 A. 10 Connective Type Usage Distribution • ....... .126 B. 1 Data Card Formats .155 B.2 COMMON Data Structures 156 C. 1a Drum Performance C.1b Disk Performance C. 2a Drum Performance C. 2b Disk Performance C. 3a Drum Performance C.3b Disk Performance Comparisons Compacisons Comparisons Comparisons Comparisons Comparisons Summing ever i Summing ever i Summing over g Summing over g Summing over 6 Summing ever 6 163 167 171 175 179 184 Vll LIST OF FIGURES Figure Page 2. 1 Processing of a Sample Query ...... 6 2.2 Stellhorn's Machine ................ 9 2.3 Hollaar Based Machine ..... ...10 2.4 Timeshared Information Retrieval Machine Model ... 13 2.5a Service Time Line for FIFO, MSCAN, and SBF 18 2.5b Service Time Line for SCAN and PSBF .18 3.1 Simulator Block Diagram ....... ...... .25 3.2 Simulator Summary Printout ............ .32 3.3a Request Service Time for SCAN ...........34 3.3b Bulk Service Time for SCAN ......... ....35 3.3c Core Usage for SCAN .........36 3.t*a Rotational Latency for FIFO Drum ..........40 3.4b Rotational Latency for MSCAN Drum .........41 3.4c Rotational Latency for SCAN Drum ..........42 3.4d Rotational Latency for SBF Drum .. ........43 3.4e Rotational Latency for PSBF Drum .44 3.5a Rotational Latency for FIFO Disk ..........45 3.5b Rotational Latency for MSCAN Disk .46 3.5c Rotational Latency for SCAN Disk 47 3.5d Rotational Latency for SBF Disk ..........48 3.5e Rotational Latency for PSBF Disk 49 3.6a Seek Distance for FIFO Disk ...... ...... 51 3.6b Seek Distance for MSCAN Disk 52 3.6c Seek Distance for SCAN Disk ..53 3.6d Seek Distance for SBF Disk .............54 3.6e Seek Distance for PSBF Disk .... ....... .55 3.7a Bulk Service Time for Drum with g=20 ... 69 3.7b Request Service Time for Drum with g=20 ...... 70 3.7c Core Usage for Drum with g=20 ... ........71 3.8a Bulk Service Time for Disk with g=20 ........72 3.8b Request Service Time for Disk with g=20 ...... 73 3.8c Core Usage for Disk with g = 20 74 4.1 A Queueing System ......... ........77 4.2a Bulk Service Time Lower Bound for 6=0.25 ...... 86 4.2b Bulk Service Time Lower Bound for 6=0.50 ...... 87 4.2c Eulk Service Time Lower Bound for 6=1.00 ...... 88 4. 2d Bulk Service Time Lower Bound for 6=2.00 ...... 89 5.1 Channel Utilization Potential for Druir with g=20 . .112 5.2 Channel Utilization Potential for Disk with g=20 . .113 VX11 Figure Page A-1 Logged in Users ....... ..... .127 A. 2 Search Interar rival Distribution ......... .128 A. 3 Search Completion Time .............. .129 A. 4 Search CPU Time 130 A. 5 System Response Time ....... ...... ...131 A. 6 Searches Per Session ............... .132 A. 7 User Response Time ........ ...... ...133 A. 8 Terms per Search Statement ...... •••••••134 A. 9 Basic Terms Per Exploded Term .......... .135 A. 10 Single Normal Term Postings ........... .136 A. 11 Single Exploded Term Postings .......... .137 A. 12 Single Search Statement Term Postings ...... .138 A. 13 Search Result Sizes Postings ........... .139 A. 14 MEDLINE Transaction Tape Sample 140 Chapter 1 INTRODUCTION Computer systems which provide information retrieval services are not a recent development [ 1 ]• Recently however, for economic and other reasons, there has been a trend toward the interactive use of such systems. During normal operation a number of users may attempt to retrieve information. The number of interactive users in the system and the complexity of their requests vary with time. The volume of data reguired and the response time constraints of interactive use result in large data bases. Efficient scheduling of accesses to the rotational storage devices commonly used in such systems becomes a critical concern if acceptable performance is to be maintained over a wide load range. In this thesis we study the scheduling of rotational storage devices in a prototypical interactive inverted file information retrieval system. The objective is to obtain a qualitative and quantitative understanding of the effects of scheduling algorithms on rotational storage performance, buffer memory requirements, and user response time. Such knowledge would be invaluable in designing effective, efficient, balanced systems to provide interactive information retrieval. In Chapter 2, the terminology used in this thesis is discussed. k model of the rotational storage subsystem is developed and contrasted with those which have appeared in the literature. System-vide and per-user performance measures are defined. Several scheduling algorithms, selected for their popularity or perceived performance benefits, are defined. To provide realistic operating conditions and to justify assumptions of the model, a review of a study of midline operation data is made. The MEDLINE study itself appears as Appendix A of this thesis. In Chapter 3 a digital simulation study of the model is described. Details of the internal workings of the simulator appear in Appendix B. Ranges of simulation input parameters are estimated using the MEDLINE data as a guide. Besults of 1200 simulations which cover the locus of operation of the model are summarized in tabular and graphical form. Complete comparison tables appear in Appendix C. The performances of the five scheduling algorithms studied are compared with respect to the parameters of the model. The behavior of the model under each of the five scheduling algorithms is approached analytically in Chapter 4. All five scheduling algorithms are studied in terms of the types of reordering of gueued reguests that they produce. Using this approach and published results, we produce first order results, with which the algorithms can be compared analytically. These results are found to be in close agreement with simulation data. Chapter 5 summarizes the results of this thesis. Suggestions for future research are made. Chapter 2 THE HODBL In this chapter, ve describe the model of an inverted file system used in this thesis. First , the concepts and terminology of an inverted file information retrieval system will be introduced to provide a background for the development of the model. Data from an operational information retrieval system, NEDLINE, is introduced to justify assumptions of the model. Five scheduling algorithms and their performance measures are defined. The complete model is compared and contrasted with those that have appeared in the literature. Inverted, File Information Retrieval In an information retrieval system a document is a collection of text vhich may be an article, report, book, abstract, etc. A s earch term is a word or phrase, with or without prefix or suffix truncation or embedded don't care symbols, by vhich documents may be retrieved. Relationa l operat ors indicate how sets of documents indexed by search terms are to be combined to produce a result set. Following Boolean logic and set theory, two common operators are * (and or intersection) and ♦ (or. or union ) . The and. of two sets of documents produces all documents that are in both sets. The or. of two sets of documents produces all documents that are in either set. A third operator, commonly denoted as -, is the relative complement or and not. The and not of two sets produces all documents which are in the first set and not in the second. It provides a more natural and efficient complete set of operators than set complement. A quer y is merely a syntactically correct combination of search terms and relational operators. It produces a set of documents vhich match the search terms of the query in the manner specified by the relational operators of the query. One common technique used in the implementation of this type of retrieval system is file inversion. All the index terms , the words which can be used to specify a document and the 'atoms' into which search terms can be split, are collected in an ind ex file. Associated with each index term in the index file is a postings list, which contains a pointer to each document indexed under the index term. To retrieve the documents corresponding to a query, the query is parsed, index terms located in the index file, associated postings lists located and then combined to produce a list of pointers to the documents. Figure 2. 1 shows how a sample query would be processed using an inverted file. Rules of the query language specify how suffixing, prefixing, and don't-care characters in search terms effect their mapping into index terms. Inverted file organization has been used in a number of well known systems such as [26]. FIND 'dog'^cat' Index File Postinqs File IF IT TIT 77 (30, 42}fl {10,30.72} « {30} Processing of a S»«pi« Qusry Figure 2.1. The inverted file organization allows as to avoid brute-force scanning of the collection of documents but does require the storage of potentially large postings lists which must be accessed at random. Depending on the number of index terms and the level of inversion, the postings lists typically range from 10* to 100% the size of the collection of documents indexed. With current technology the only feasible storage device which provides the required random access are the rotational magnetic devices, commonly called disks and drums. For the purposes of this thesis a disk is considered to be any rotating device which may require physical motion of the read/write heads to access a record. A drum is any rotating device in which electronic selection and rotation are all that is required to access any record. is examples, the IBS 2314 and 33 30 disks are disks and the Burroughs B475 head-per-track disk and IBM 2305 drum are drums . By storing all entries of each postings list in sorted order the computation of union, intersection, and relative complement can be performed by merging postings lists and casting out approprate entries in the result. For example, the union requires deleting one of each pair of duplicates in the merged list while intersection requires deleting all but one of each pair of duplicates. It was observed that this simple, repetitive merging task is often inefficiently performed by general purpose computers [6]. In the past two years special purpose hardware which quickly and efficiently performed some or all of the work of processing a query has been designed [4,5]. Stellhorn*s 8 machine. Figure 2.2, is based on a parallel Batcher merging network followed by a coordination network which handled the casting out. The system was designed so that postings lists could come either from the random access buffer memory or a fast head-per-t rack disk. Hollaar demonstrated the design of a small merge processing element which could be combined into merge trees that paralleled the logic of the guery. For the purpose of our discussion, we assume the inverted file system shown schematically in Figure 2.3. This mechanism is similar to Stellhorn's but based on a tree of Hollaar processing elements. This approach reguires that all postings lists be available in random access buffer memory because of the data dependent order in which postings list entries enter the processing elements via the distributor. Note that since the postings lists are always accessed in the sorted order they are stored in, true random access is not reguired. It is sufficient to be able to serially access the entries. Banks of shift registers are a possible alternate technology for the buffer memory. llie HEDLINE Data To model an interactive inverted file information retrieval system realistically, the behavior of the users who provide the workload must be understood. This section provides an overview of the results of a study of a day's traffic file from MEDLINE. MEDLINE is an online version of NEDLAfiS (HgD ical Literature v, CO 5 § t't: 2Jl >- < 2 Q UJ 2 0) e •H XI O • * »- - Q -» 10 i m rs 1 N 0> oa 9 U •* * to e ■ 11 Analysis and Retrieval System) , a service of the National Library of Medicine. MEDLINE currently stores citations on approximately one half million articles from 3,000 American and foreign medical journals. Citations are added at the rate of 75,000 monthly. Over 300 libraries, hospitals, and medical schools use the system. The complete study, including details of the data collection and possible shortcomings of the study, comprise Appendix A of this thesis. This traffic file covers the 19 hours of operation on Monday, January 13, 1975, and was provided by Dr. Davis McCarn of NLM. We conclude from the MEDLINE data that the distribution of query interarrival times is approximately Poisson (Figure A. 8 of Appendix A). This fact suggests that an infinite source model, rather than a more complex, state-dependent finite source model, is reasonable. The observed distribution of index terms per query (Figure A. 2 of Appendix A) , even after correcting for ex plod es (Figure A. 7 and Table A. 5 of Appendix A), can be modeled as a geometric. Explode is a construct particular to MBDLINE but an embodiment of a concept common to information retrieval systems. The concept is that a single term can be elaborated into many terms. In various systems this is handled with macros, thesauri, personal dictionaries, or tree structuring of the index terms. MEDLINE, which has a controlled or predetermined vocabulary of index terms, uses a tree structure to reflect relationships of index terms: broader than, narrower than, subsumed under, etc. A single exploded term in a guery would cause the retrieval of many index terms and their postings lists. 12 Data collected on the complexity of queries and sizes of postings lists are discussed in Chapter 3 with respect to the estimation of simulation parameters. Other results from the MEDLINE study will be mentioned throughout the thesis as they are needed- The Model Figure 2.4 shows schematically the model of a timeshared information retrieval system used here. A query is modeled as the simultaneous arrival of a group of secondary storage access requests, called a bulk . These requests are queued in a controller which selects individual requests and serves them serially. when a request is selected for service, buffer space sufficient to contain the postings list to be read is allocated in buffer memory. Buffer space for each request of a bulk is held until all requests of the bulk have been served. At that time all buffer space for the bulk is released. This corresponds to the operation pattern of a Hollaar merger, which requires all postings be core-resident before any merging begins. The time required to access a single record is the sum of the seek time, rotational latency time, and transfer time; ve call it the request s ervice time. The seek tj.me is the time required to position the read/write heads over the cylinder containing the desired record. For this work, the seek time is assumed to be a linear function of the seek distance. The seek distance is the positive difference of successive cylinder 13 arrivals at rate A bulk size q Merqe Processor Queue Timeshared Information Retrieval Machine Model Figure 2.4. 14 • addresses. The r otatio nal latency is the delay between the completion of head positioning and the start of data transfer. This delay is due to the rotational nature of the storage device which provides only periodic access to any location on the cylinder. The transfer tj.m e is the time required to read the desired record from the device into the buffer memory. Due to the periodic nature of the devices it is possible to begin transfers in mid-record and later pick up the first portion of the record. This trick can reduce latency in cases where part of the latency would be due to passing over the end of a record while waiting for its start. It is not considered here; all transfers begin with the start of a record. He also assume that the request reguires at most one seek, exactly one rotational latency, and exactly one transfer time. In practice, this means each record exists in one piece on one or more tracks of a cylinder for a disk. Clearly, the seek time depends on the distance from the last position of the read/write heads, which was determined by the address of the last reguest serviced. The starting position and record size of the last reguest serviced also combine with the seek time and starting position of the current reguest to determine the rotational latency of the current reguest. Hence the order in which reguests are serviced affects the reguest service time. Only the transfer time portion of each reguest service is independent of the state of the device or order of service of requests. The transfer time provides a lower bound on the request service time and the ratio of transfer time to 15 request service time is a measure of the efficiency of the request service. The followinq assumptions are made reqardinq the model in the remainder of the thesis: 1) The arrival of bulks of secondary storaqe access requests is a Poisson process with average arrival rate X- 2) The number of secondary storage access requests per bulk is a statistically independent, identically distributed (IID) qeometric random variable from the set of positive integers with expected value q. 3) Each secondary storaqe access request has an address tuple (c,r,l) which, along with the bulk it belonqs to, fully characterizes the request. The cylinder number c is a random variable chosen uniformly from the set (1 ,2,3, ...n) , where n is the number of cylinders of the device. The startinq rotational position is a random variable chosen uniformly on the interval [0,1). The record length 1 is a random variable distributed exponentially with expected value 6. For different requests, c, r, and 1 are statistically independent. U) The state variables C and E, the current position of the read/write head in terms of cylinder number and rotational position, respectively, fully characterize the state of the device at any time. Auxiliary state variables may be introduced in each scheduling algorithm to qualify these state variables. The distributions for bulk arrivals, bulk size, and record lenqth conform to those observed in the MEDLINE study. The distributions assumed for cylinder and rotational addresses are based on the use of an unformatted disk. In such a system no attempt is made to distribute postinqs lists on the device by size, frequency of access, or loqical or lexical adjacency in the 16 index terms. It is conjectured that formatting could lead to reduced service times and better balanced merges [13,21]. The lack of data on logical adjacency or access freguency and the computational complexity of even sub-optimal placement procedures make formatting a formidable task for static document collections. In a dynamic collection such as HEDLINE, the cost of constant reformatting could well be prohibitive. For this reason, no veil known system uses formatted devices. Meas ur e m ents and. Pe rforman ce Metr j.cs To evaluate the performance of the five scheduling algorithms considered here, the following three performance measures have been selected: 1) The bu.ik service time is defined as the time from the arrival of the bulk to the completion of service of all the requests comprising the bulk. 2) The regue st servj.ce tjjne is defined as the time from the selection of a reguest for service to the completion of data transfer. 3) The buffer occupa ncy is the time weighted amount of buffer space in use by all bulks in the system as their reguests are accumulated. Let us briefly consider the implications of the three measures we have just defined. The bulk service time is of central concern to system users, as it largely determines the system response time to user gueries. The request service time is the cost to the system to service one member of a bulk. In non-bulk arrival systems this measure is commonly minimized to optimize performance from the viewpoint of the system. Buffer 17 occupancy measures the cost of spreading nrembers of a bulk in time as a result of reordering service to reduce reguest service time. Since buffer memory is a limited system resource, the demands that a scheduling algorithm places in terms of space are important to the system. It will be shown that some algorithms trade increased buffer usage to improve bulk and reguest service times or, conversely, that at fixed buffer sizes, algorithms have differing bulk and reguest service times. Overlooking the connection between buffer usage and device scheduling proved to be the cause of unexpectedly poor performance in Stellhorn , s multiuser simulations [ 4 ]. Sche dul ing Algorithms Scheduling in general can be viewed as the art of selecting a permutation of the work on hand that minimizes some cost function. The three performance measures defined above can all be viewed as cost functions, to be minimized individually or jointly. We now define five scheduling algorithms which we compare using these performance measures. FIFO: The simplest and most obvious reordering of the requests in the queue is in fact no reordering at all. Each bulk is served in the order it arrived. The requests in each bulk are served in the natural order they appear within the bulk. Because of the assumptions on the (c,r,l) tuples, this is equivalent to service in random order within bulks. The time line diagram in Figure 2.5a illustrates the behavior of one bulk under FIFO request service ben ins bulk service beqins other bulks in service tine buffer space seized done Service Time Line for Firo, HSCaM, and SBF Figure 2.5ft. 18 + core usane requests of other bulks in service + core usane Service Ti»e Line for SCAM and PSBP Figure 2.5b. 19 service. The initial delay is due to waiting for previous balks to complete their service. Once the system begins to service requests in this bulk, buffer space is seized as each request of the bulk is selected (vertical axis). All buffer space is released when the last record transfer is complete. SCAN: One of the most commonly used reorder inqs is produced by ordering all outstanding requests by cylinder number to form a cylinder ordered queue, when a bulk arrives its requests are immediately merged into the cylinder ordered queue. The read/write head sweeps back and forth over the cylinders, alternately servinq the queue in ascending and descending cylinder order. The direction of the sweep is reversed when no requests remain beyond the read/write head in the current direction of travel. This approach reduces discrimination against outside cylinders which occurs in a shor test-seek- time- first (SSTF) scheduler [15] where the choice of direction is a function of distance to requests in each direction. The time line diagram in Figure 2.5b illustrates the service of a single bulk under the SCAN policy. Notice that because the policy is sensitive only to the cylinder address of a request, requests of a qiven bulk will generally not be serviced consecutively. Rather, they are interleaved with requests from other bulks. MSCAN: In this policy each bulk is serviced in the order it arrived, as in FIFO, but requests within each bulk are serviced as in SCAN. Figure 2.5a also illustrates the behavior of this 20 policy on the time line diagram. The direction of motion of the head is controlled by the same rule as in SCAN and may produce sub-optimal seek patterns around the boundaries between requests of different bulks. SBF: Once the reordering of requests is confined to single bulks as in MSCAN, attention turns to the reordering of whole bulks with respect to their arrival order. Under the policy of scheduling the shortest-bulk-first (SBF) , shortest is determined by the number of requests in a bulk, with ties broken by the smallest total record length. Once a bulk is selected, all its requests are served as in SCAN, without interruption. The time line diagram for SBP is similar to Figure 2.5a. PSBF: An immediate variation on SBF is to allow a newly arrived bulk to preempt the bulk currenty in service if the new bulk is shorter. This preemption will take place at the end of the request service cycle in progress when the preempting bulk arrived. This policy allows small bulks to pass larger bulks while the later are in service. When a bulk is preempted a transition between requests of differing bulks is made and the head travels off servicing the requests of the second bulk. When the service for the second bulk is completed, the head moves back to the neighborhood where it was when the preemption occurred. This generally results in the completion of the remainder of the preempted bulk in two rather than one segment. The time line diagram for this policy resembles Figure 2.5b. 21 To this point the question of the scheduling of requests on the same cylinder has been ignored. In the case of FIFO, if successive requests happen to be for the same cylinder they are still served in the natural order. For SCAN, MSCAN, SBF, and PSBF, if two or more requests for the same cylinder are schedulable (for all but FIFO and SCAN this means they are members of the same bulk)* they are scheduled shortest-latency-first (SLF) . Coffman [ 16 ] observed that seek scheduling and rotational scheduling are independent. It has also been shown [22] that SLF is nearly optimal, requiring at most one extra rotation over the optimal schedule. Chile optimal schedules for the small number of requests likely to co-occur on a cylinder are not hard to compute [25], SLF is used throughout this work for both its practical and analytic simplicity. Simply from the definitions of the scheduling policies we can make some guesses as to their relative performance. The reordering in SCAN reduces request service time because it reduces seek distance. Its net effect on bulk service time and buffer occupancy will depend on the net effect of interleaving which reduces request service time but also breaks up requests of a bulk, which in turn causes the effective size of each bulk to increase. To improve request service time over that of FIFO but avoid the possible disadvantaqes of bulk interleaving produced by SCAN, the hybrid policy MSCAN was developed. MSCAN takes a middle approach, reordering only within the bulks. It should improve request service time over FIFO but avoid excessive bulk service time and buffer occupancy. Using SBF we expect to reduce 22 average bulk service time over MSCAN. It is veil known [33] that if order of service does not effect service time, then shortest service time first produces mimimal average flow time. Notice that we make no attempt to consider the effect of reordering bulks on the transition between the last request of one bulk and the first request of the following bulk. He also know that the order of service does effect service time in our case, so from [33] we can only conclude that SBF should be better than FIPO (which is really service in random order (SIRC)). He can compare SBF and PSBF by noting that seek distances are increased and request service time suffers during preemptions which occur in PSBF. Literat ur e There is a vast body of literature on both disk/dram scheduling and the larger question of computer system simulation. The current work is patterned after the pioneering effort of Scherr [10] in the modeling and analysis of CTSS. A good treatment of the scheduling problems of disks and drums appears in [16]. Several papers have appeared in the area of performance of disks and drums, including [11,12,14,20,22]. Horks which compare various scheduling policies include [15,23]. The most recent analyses of disk and drum performance are those of Fuller and Baskett [17] and Oney [19]. Their works parallel, for the single request per bulk case, the analytical development in Chapter 4. 23 In terms of the current problem, the major deficiency of work to date is that all bulks were of size one. Attempting to project these results directly to the more general case results in a fallacy of composition. Ihat is best for each request individually is simply not best for requests considered as groups. 2M Chapter 3 SIMULATION STUDIES In this chapter a study of the five scheduling algorithms is made using a digital simulation of the model. An overview of the simulator is provided, with details deferred to Appendix B. Ranges of input parameters of the simulation are estimated using MEDLINE data as a guide. Questions of convergence and stability of the simulation are discussed. Samples of tabular and graphical results are presented. Summary results of the 1200 cases simulated are presented and guantitative conclusions on the relative performance of the scheduling algorithms are drawn. Sjmlulator Overview The model described in Chapter 2 is simulated using an event-driven simulator coded in FORTRAN IV. The basic structure of the simulator is shown in Pigure 3. 1. It consists of an event-list management package and a group of event routines. The event- list management package maintains a list of all currently scheduled future events as (event, time) pairs. Events are added to the list as reguested by event routines and removed by the management package when time advances to the event. In a basic cycle the management routine sets the time to that of the event at the head of the event-list (advancing time), removes the event from the list, and calls the corresponding event routine. The 25 \* ■ii , Event-list manaqement 1 Bulk arrival Event Seek complete Event Transfer complete Event \ < " [ ' Simulator Block Diagram Figure 3, 1. 26 event routine performs some computation, possibly altering the queue of pending access requests, and calls management package subroutines to schedule one oc more nev events. It then returns to the management package vhich repeats the cycle. The queue of pending access requests contains all the (c,r,l) tuples corresponding to pending requests in addition to a system of links which maintain per bulk information and provide all the information necessary to schedule the requests by each of the five algorithms. Additional tables and variables maintain state information, record performance statistics, and collect distribution information on input values. The performance statistics provide the desired information on the effects of the scheduling algorithms while the input distribution values provide a check on simulator operation. The unit of time is one rotation of the disk or drum and all quantities with dimensions of time are measured in this unit. iD£lii Para meters To simulate the behavior of the model it is necessary to supply numerical values for a number of variables. Three of these variables, average bulk arrival rate A, average bulk size q, and average record length 6, specify the input load characteristics- The characteristics of the disk or drum are specified by the number of cylinders (one for drums, two or more for disks) and the two coefficients of the linear seek time function. The scheduling algorithms to be used are embedded in 27 the simulator and one is selected for a given run by an input parameter. The amount of time to be simulated, the number of bulk arrivals to be simulated , and the number of independent samples to be used to compute confidence levels are also parameters. In this section we deal in turn with the determination of approprate values for all these parameters. The average bulk arrival rate, X, the average bulk size, g, and the average record length, 6, characterize the modeled user load. To facilitate comparison of results for varying bulk sizes a secondary variable, i, defined as Xg, was introduced. Called the arrival intensity, i is the average rate at which access requests arrive in the system. The choices of values for X and g were engineered to produce only a small number of values of i. This allowed the comparison, without interpolation, of the effect on the system of differing bulk sizes at constant average input load. Using the analytical expression for the average service time for a FIFO scheduled request the disk system saturates at a value of i of approximately . 32. Short test simulations for the other four scheduling algorithms, in which values of X and g were altered to produce larger values of i until the system saturated for each algorithm, produced an upper limit at about i=.55. To cover a fair load range a set of six i values (.05, .15, .25, .35, -45, and .55) were selected. Given these values of i, knowing either g or X would determine the other. Since data on the number of index terms per query was available and since this distribution is independent of 28 the number of users, g vas estimated from the MEDLINE data and X derived from the defining equation of i. The data indicated small searchs were very common (Figure A. 6 of Appendix A) • In fact, before correcting for the effect of explodes . the mean number of index terms per query vas 1. 92 with a standard deviation of 0.99. By hand count the average number of postings lists associated with an exploded term was 3 0.25 with a standard deviation of 50.97. Using statistics on the frequency of exploded terms, the ad-justed average number of index terms and hence postings lists per guery is 6.50. While these numbers appear small they are in general agreement with observations of EOREKA users [3,9]. To hedge against the possibility that searches are small because, in MEDLINE, large searches are very slow, a wide range of values of g was selected. The values chosen were g= (2,5, 1 0,20,50) . For each value of g the set of i values and the relation i=Xg defined a set of X values. The initial value of 6, 0.50, was chosen after [17]. MEDLINE results provided proof that the distribution was approximately exponential and established expected values in terms of number of postings list entries. To convert from numbers of entries to fractions of a rotation it would be necessary to assume entry sizes and track capacities. Using numbers typical of current devices, entries per rotation range from 1500 to about 9000. MEDLINE data suggests postings lists average 601 entries with a large standard deviation of 1160. An estimate of 6 in the area of 0.50 is consistent with these measurements. To provide a margin for error and to detect any 29 differential effect of record length on algorithm performance, four values of 6 were used, 0-25, 0.50, 1.00 and 2.00. The value of <$ =4.00 would produce a case where transfer time dominated the request service time. As discussed earlier, under these conditions, limiting case analytic models should provide accurate predictions. Halving the lowest value of 6 would only reproduce the behavior of the 0.25 case, as for current devices the seek and latency are dominate in this range. The selection of the number of cylinders and the seek time parameters were a matter of discretion. As it was now apparent that the number of cases would be large, only one disk and one drum configuration were selected. Since the model admits only one possible drum configuration there is no loss of generality here. However, for the disk there are three parameters, the number of cylinders, incremental seek time (time to move one cylinder once the arm is moving) and seek start/stop time. For the disk simulated these three parameters were chosen to represent a 2314-compatible disk with maximum/minimum seek times of 75 and 10 msec. To compare the five algorithms each was tested for all possible combinations of parameters. He call each distinct set of parameter values (i, g, 6, device, and scheduling algorithm) a case. Since there were 6 possible values of i, 5 values of g, 4 values of 6, 2 device configurations, and 5 algorithms, a total of 1200 cases had to be simulated. 30 Since the amount of simulation time necessary vas clearly going to be large, a careful study of how long, in terms of simulated time and bulk arrivals, each simulation, or run, vould require and how many times each case needed to be repeated to provide small confidence intervals was made. The length of the run determines how completely the transient effects of the simulation startup have died out and how smooth the statistics gathered will be. The number of repeated runs determines how small an estimate of the uncertainty of the results can be made. Independent but otherwise statistically identical runs are produced by not resetting the random number generator between runs. Tests were made for 100, 250, and 500 arrivals per run and 5, 10, and 20 runs per case. Using the FIPO algorithm, for which exact results could be predicted, simulation output was analyzed. Based on the cost, which was proportional to the number of bulks times the number of runs, and the slow, less than linear improvement in accuracy, a bulk size of 250 and a repetition factor of 10 were selected as the best affordable combination. Using this combination, time required was estimated to be 27.9 hours on the CSO 360/75. Due to early termination of several runs in unstable cases, where queues outgrew the simulator's capacity, the actual time reguired was only 26.8 hours. Results The amount of results produced defies hand analysis in tabular form. Straight-forward plotting would require a surface in four-dimensional space for each combination of device type 31 (2), scheduling algorithm (5), and result (3), By plotting each result as a function of arrival intensity foe constant record length, device type, and scheduling algorithm and plotting the result curve for all values of g on one graph, the data vas reduced to 120 graphs, each with five curves* Samples of tabular and graphical results appear in Figures 3.2 and 3.3. The vertical bars in Figure 3.3 indicate the 95* confidence level interval for all data points for which two or more runs, out of ten, were stable. The crosses plotted along the curves indicate the interpolated estimate of the utilization or traffic intensity, the ratio of total busy periods over total simulated time, of the device for values of 0.2, 0.4, 0.6, and 0.8. It provides an indication of the level of saturation of the device for the given conditions. The results of a qualitative hand reduction of the graphical data for the 231 4 type disk and 5=0.25 appear in Tables 3.1a, 3.1b, and 3.1c. The six arrival intensities were reduced to three pairs, with 0.05 and 0.15 being low arrival intensity, 0.25 and 0.35 being medium, and 0.45 and 0.55 being high arrival intensity. The algorithms are denoted as in Chapter 2. Brackets group algorithms which were judged equivalent in terms of the result being tabulated. Notice that in Table 3.1a SCAN appears to be the best scheduling algorithm in terms of request service time but in Table 3.1b SCAN is one of the poorer algorithms in terms of bulk service time. In Table 3.1c SCAN and PSBF are observed to do worse than FIFO in terms of core usage. The effect of reordering to reduce request service time does not OCO I I --T 4> 4- + t» u-r- «* ■ u r-n.c- • • • 000 I I I \I *■ 4- 4- cl a OOro| — T\jf- -r m i> j- I I I i; • • « OO.J I I I »- ■f + -H-0 fMAOisj .n>ocj-r o^~ • • * o-ow co* *mr- CJO j- • -J-* i • * CO* qc-vC* L.~ J- * » « t i>cr » r^ •* K » ■oi"" « •f •> » 5 oo * Q ,• » " • • >' • •» 1 « ^-r* o III* I i i -r i ♦ + 4-f>~ * -t. + ^ 4- » * PfTHf p— <\ 4 *• Orvo >»■ ** • •— <\m o • * « • • B • a ■« *• *Ot> o I 1 1 r. 1 1 1 IM | 4- 4- +n 4- 4. 4- O 4- —•no--* x.j- -o -< C c • • t • f « • cp^-.m *m.in o >CC -O sj-»*in ~>o (N m* -l. mO* in ■0* v .0— '« f> r- » * o^c V C •I 1 i. • •* • m* * r^O-f O i i 1 m 1 1 t S\ | 4- 4- 4-c 1 4- 4. 4- n 4- -*>o n-i T^rO -< r~ --\Orvi O-J--* r~ *c>* fNjT^ JO >»■ (M-- .•~r-f- a inr-in in.r>r-»■# 7^4rH O o-it r ^* <\/f-* ^jv # O * • * • 41 ■» • (V*. * t~-* 1 O 1 1 1 o 1 1 1 O I 4.4-4.0 + 4. 4- O 4- 3v»f--iN -re- LI rv O -C*~* M.-VO -* Jxg- r--orj (\4 • • t • • « • UT* ~or^ i^r-rn O cic in f-^Hj f\l — «,-icr r^-a-* * 4" * IA .nX-fr * t s O LOnT ii * * * o . . » » V # • -|<\; a * * 41 o II 1 If 1 1 1 •^ 1 I + * +f 4-4-4- .-T) 4. O — r~-f\ ^j-piri (\l —1 C rr^- ^-(""O I-- or* so k»(VQl o • • # • • < • hCC — X.fTI o ^ir , !» — — ■ o— o o —IS c c u-Z >— Li— • — L_ 1/5Q. -JO. 2S OUJ OUJ CO. —•a »-►- f^rOoflO IN -4>C# 0rf\j-^st vX OOUIP -Olll-I Z1>UJ LL1UJ'-' JCL0(- -f 0« •■4 3> » r>T u • •* in** 1 1 1 »M 4- 4- 4- * *r-* T •fTrr- S\ m-o< • • • ono iNirv.^ r--o» CCO-ti (NJCC* • •» ^(«-l» 1 1 1 O 4- *• 4- in r— r-~(x * roOiT) in 00 4- r^ • • • njcor F^^nt "^ •S-Q # r~-rr,» o-^i# • •# 1 1 1 CO 4-4-4- x\ o.*\ $ O \Jv ft OO* CO J-tsj -40 —4 'NJ">-» or* •n^i* • •■» 1 1 1 1*1 4-4- 4- ■a •lOINI * mr— iv in r-r-cc • • • -roo' — 1» f~-0t — --*.ni^ a-'«i • • • ~^*-« j-Ijj OOS _i> OO 1 1 1 _d < j JUU: +■ 4 4- ■*- >i-T <: ^isi Oinrr * >o— moo Li L-O tr r-oc U.O >-U- • • • K '4 — Otu C*-C i_r 5. <-> r- UJZ- — arc < U,l/". !■«/■. 11 »-« ^ u u .J -0 Uj ujO X Q_< □ l/l < i-)=3 ai • 32 o e •H M Cm U • r: u -^ to « ■ •H CO 33 y ii ui — j < > o* -J + 75 x O « • S" o h x> IUZ 1 ii >: c u.-- y r~Jr-X> — 5 l/- ^ ► - U.!XiS «di— o.' II ct- _JuJ OjO >coc q < i — ■ - >- II ^ o — C Cl-I- dcc<3 C O .J- c ii cr. ITu _ mxc a '<. > a. v. a <: _i< ! • ii c II >- UJl/ >cr v (_' _;c ~> o II LT. _l > Oa: Ok o* _i x:o * Oil mc Oct y H 3 iuz ?■ •— 5" r-X> >: li_ Xl/I llv<3U. on>. _> a co >r*u i_oc ociu »-►- od_ _i*4 ~ >z) ii x-i •-•<"}.*. r. a K. IT < 'Mrr u I— r o"> < o. ."•: u-^-» c--o <-1_u. OX— I >_J U.u. oC II OH >c oo CTj■ -?LL lAOUCD OvlO •— — «OU r-r- ootk: . . h-C OCiC, r\ju. nf '^> II II K IL' UIU.:?" iL —1 r-r-JXCa (X^> a «a < u X _i o— O-i Oof" On OJ^ Oa; ■J-< -»■< • • Oit O^ _ —1 + n ■f o xct xcc « V Ou. ou. fOC mo O-l 0"< OOH OOuJ O »LL O «UJ moor mocc • t: • s - our O II ~- o u;z o LUZ • II ST 1 II £ ca;«y o ^•-•5: Mr-I Mr- — ii — i; II — • 5: jji^^>- L- u * — 1- U..X ir. \~ UJXU" Ci OC S HOC \X "NJ 1 _i (T rsj ._ U u. c < u_ C< tr c." ii r~. r- 1/ C II Ch cc O I" >GCC X**i_ — ^^ CC < 2! r-l»- ■— II — II _il/ — II/ - * >; U. V2TU .IOuC o tr OoOC i^o •- (N o «- HCIlr- t- r> OLLr-r- ooo < 3; q oc«.: • • t- o < • ht. OOXC c OdC P-Jl-U.T oo rv-u3..' II II cc LU II ii ci a UU ?"IL -J a 'uSTU. - r--J_^C c K isjXC n. <•— t<\T IL, <■ _i fllk -KIT _l > X' Ii X' — •- trio: O X •C a X <3 N> a.i_K^ iyi ir\i u.>-r"o •^o—r: Z* < C"— »xx < lZ um _J< _!< <- CC< »-rs _ <- ^ Q.l/' o (VJ ii _j < > o— OjC Ott • o>j _l + X1 X03 » Oa. mo o-< ooa o «UJ ir>|oco E O II X> U-'Z > H cu X iW^r— • U-Xl/J o:v X II X>_J — m s zia x < <">a'U. f-S">/l ■tfC— xo <.o.3L uj^o. X — O >/i_ju. OX-^ -l< a o C • •H -. M • e u u I u a) o u ** 9 • Ot rH'H »U s V) 34 rvj 10 o o d < .1 % V V CO /■ \ en CM C_) 01 hH W W H + OS'S -I- 1 1 00*6 OS'l 00M OS'O 3WI1 33IAy3S i93flQ3U IT) (VI LO O in en z in e'- en U N * • U M •H ► &» o QC 9 encr a o 0" in CVJ c\j o in in o o o 00" 35 CO I 1 / s CO CYJ CE (J~) ■+- -f- 0*9 0"ti O't 0*2 O'T ( aOIX) 3WI1 33IAH3S Hina O'C 36 I 1 CO CYJ en O'OS a M • U u n O • • • « m • 9* I* s o u 0"0h D*0E 30BSn 0"02 3d03 O'Ol o'er 37 2314 Type Disk Results ^ arrivarv service fast slov low medium high [ MSCAN, SCAN, SBF, PSBF] SCAN [MSCAN, SBF] PSBF SCAN [HSCAN, SBF] PSBF Bequest Service Time for 2314 Type Disk Table 3. 1a. FIFO FIFO FIFO arrival\ service fast slow low medium high PSBF PSBF PSBF [SBF, MSCAN] SBF MSCAN SBF SCAN SCAN SCAN HSCAN FIFO FIFO FIFO Bulk Service Time for 2314 Type Disk Table 3.1b. ^ arriva]\usage low high low medium high [SBF, HSCAN] PSBF [SBF, MSCAN] PSBF [SBF, MSCAN] FIFO SCAN FIFO PSBF FIFO SCAN SCAN Core Occupancy for 2314 Type Disk Table 3.1c. 38 offset the increased dispersion of requests of a single bulk under these conditions. A complete tabulation of the numerical results, includinq histograms of most distributions, runs 2400 pages plus 30 paqes of index. Due to its length it is not reproduced here. Comparing A lgor ithms The performance of disks and drums depend to a measurable degree on the algorithm used to schedule the service requests as well as on other parameters. In this section a brief review of the apparent effects of the parameters on performance is made. The simulation results indicate that performance at constant arrival intensity improves with increasing bulk size. At constant arrival intensity bulk service time grows less than linearly with bulk size. The utilization at a given arrival rate decreases as the bulk size increases, indicating more efficient handling of larger bulks. Bequest service times decreased with bulk size for all but FIFO, indicating that greater freedom in the reordering due to larger bulks was beneficial. Core occupancy also grows less than linearly with bulk size except for SCAN and FIFO. Bulk service time grows faster than linearly for all scheduling algorithms as a function of arrival intensity. This appears to be due to the buildup of queues, as request service time is constant for all but the SCAN policy as a function of arrival intensity. Recalling that the SCAN policy optimizes 39 seeks over all available requests and that the number of available requests will rise as arrival intensity increases, we note that the decrease in request service time as a function of arrival intensity for the SCAN policy is not surprising. Core occupancy grows worse than linearly for the SCAN policy, due to the increased interleaving of bulks as we speculated in Chapter 2. All other algorithms exhibit near-linear core occupancy growth with arrival intensity. He recall that varying average record length, 6 , changes only one of the three factors in the service time. If the average record length is small its contribution to the overall service time will be slight and the seek and latency characteristics will dominate the total distribution. Conversely, if the average record length is large enough, it will swamp the effects of seek and latency. For the FIFO policy the seek time and latency time contribute 88% of the request service time for 6=0.25. For average record lengths of 0.25, 1.00, and 2.00 the contributions of seek time and latency time are 80%, 6U%, and 47% respectively. The rotational latency time is shown in Figures 3. 4a-3.4e and 3.5a-3.5e for drum and disk respectively. For the drum case the latency is a function only of g for all but the SCAN policy. Figure 3.4c. This is due to the fact that only in the SCAN policy is the service of bulks interleaved by scheduling. Clearly the effect of the interaction between requests of different bulks will increase as the number of concurrent bulks uo I ID a % K L. 1 I 1 8 l/l ffl 9 z LU to a: > of 1 K O w IS « e m a B + 09'0 + Bh'o 9t"o hs'o ero JL0N31U1 lUNonwioy a o a 00 r (P 41 ZD Q CE en a x I — I n WJt Hrf w H pjJJ W)C o S il H H H M H wj: H M M *o: H H H U1 (\J 1/1 a Lfl d en LU d > g CC d ft! a a r- o u • U A 0» 9 ►4 h 8 s •H o as + o a o 09'0 9h"0 9E/0 h£"0 Sl'O oo -rf 3 42 2 QC t CE CO + 09'0 *i:c t o 3 w .:< H H I H M H M M + H * 4 + Bn'o 9fo h£'o ero s s en ■ U Q U in CT > DC ex R O U s: 4J ** Hi -H e o •H *i fi UI O O -4? 00 0° H3 ZD QZ a U7 A M H tolj d en Ll_ CD CO M W mi n M 1 c3 H H M N < H H I wj: M M 09'0 + +- H W H -4- Bh'o 9t*o ht'o ero XDN31U1 iHNoriuioy a 8 in Lfl in O en LU in a: > R ft in o o a a o 00 cP S u a * CO (0 u • o •« unco u e • M ** * & i-l-H ft- « e o -4 O 44 21 CO Q CE C_J cn w«{ m CD W M I S I H njj WJJ M *>:< M H «uj: h I H >i M a 3 tf 1 a in ■■-•>- * o 2 UJ in a: > in U t o • U fi « R c a: o « c o •H *l 4 e JS in a H H H X r- o h- 09"0 + + Bh'O 9E/0 h£"0 ero a a o 00 0° 45 en i 1 / s T (0 %. on h \a N___ Ll D * i — i Sj: 09*0 8h"0 9£'0 hS'O Sl'O a s CVI Ln in a CD LU in o DC en a: CD in n a in □ LP r- o a CD a a 00 '0° <46 CD Q s 1 en CYJ C_3 a LJ X 2 09 - wd a tQ;, iD OJ =*•;< ,: ,ivj>: 8h'0 9£'0 hd'O Sl'O 13N31U1 lUMOIlUlOy S a LD o tn o en 2: LU in a: > M u (A U X» o m c ^ V in 8 « o as LP a in a a a OO'CP 47 CD I 1 a en CAJ ex CO 09*0 MAC r t ti jb ^ •jj ^:c tf.< r «u< KMIH *:.< *J< r m W T In j ::< RJJ{ MW H Bh"o 9£-o ne'o ero § H a in o in o o a a a 00 if n u m u • o o o B t> • U *i * «r ►4-H en > g GC 41 « ♦J O m in ru OJ <*8 on C\J CL LJ CO Li_ CD CO 09"0 aim? d cJttOJ o PO U);; Ljl •SI 5 *; Hi I *Ji 5^: h«W « + + Bh'o 9£"o he"o ero iJN31dl lUNOIldlOy a s en ru a in d LU in CL > □ oc en a; D LP OJ OJ D LP un o a o oo + + Bh'O 9E.0 he"0 £1*0 XDN31U1 IHNOIiyiOy a 8 un a un »— • en UJ LP > l R .ac 5 Lfl o a o o 00 0° 50 grows with the arrival intensity. The value of g has the very visible effect of reducing average latency as g increases. This is a manifestation of the increasing freedom of choice in SLP scheduling of requests of each bulk. In the case of the disk, the average latency time also decreases vith increasing average bulk size but at a much smaller rate. Since SLF scheduling, which is responsible for the rotational latency behavior, requires a number of requests per cylinder to produce improved latency, the cause of the smaller rate of decrease is clear. In fact, it must be true that the expected value of the number of requests per cylinder is very close to one. For example, the g=2 curves for the drum lie far below even the g=50 curves for the disk, as can been seen by comparing Figures 3. <*b-3. Ue with Figures 3. 5b-3.5e. Figure 3.5c, the disk under SCAN, shows some decrease in latency as arrival intensity grows, indicating increased probability that multiple requests occur for single cylinders. This effect is due to the increased odds of more than a single request per cylinder brought on by consideration of the requests of all bulks which occurs in the SCAN policy. The effect is correspondingly diminished over the drum case, for the reason just given. Figures ?.6a-3.6e show average seek distance as a function of arrival intensity and bulk size. Seek distance rather than time was selected as being more general, since seek time is a function of technology rather than geometry. These plots are for =i disk of 200 cylinders but they can be scaled up or down for oLner disks, as long as the number of cylinders remains 51 I (J~) a i (Q ») U_ i — i j_ 0"SL 0'09 + +■ O'Sh O'OE O'Sl o § a CD UJ in d (X >• i— i a az m cr o KJ a in a-* a" in r- a 4 a 8 o :

u O c ey w • (A 52 01 I 1 o 1 en «.3c «;s CE C_J CO CD UJ X I 1 *Ji ■43! ^ O'SL 0'09 i Btfjj ■oj: J ,3: (u ): o'sh Q'oe 33Ndisra M33S 5 l\J(l II § I hi I *>3: «qii » r .x H II *3! r .;« H H (V) ai Q'Sl a 8 d in in CD LU i/i I— r- ~z. on . fl u 13 XJ SO U • O 1*1 CL cn i (X g w a M • 4) o a in 5 a o «f 53 cn I H CD s 1 CO (\J CE LJ CO f— O'SL Q'09 -h +■ O'Sh O'OE O'Sl HI in o in 3" in z UJ IS en a: R o HI CVI U U • o *n • U O S T> a j* V (0 54 CD a *>:' en C\J «>; u^r 1 r .): U CO in "XX UJj{ H *>: w.3! 3 «»,ll *.JC H m;| ^ H «;< *.): •- H (u ;: «435 o in o o CO 2 UJ r- > •—I a CC ma; a o a + + + a a o O'SL 0*09 0"Sh O'OE si 0° en i 1 Q (U «>: on CM *;< «>: cr CJ en CD en *>! *;< H M t ^: W)| O'SL 0'09 + 4- O'Sh O'OE 30Ntiisra M33S o 5 hi 4 I »): HH *.): (■I w* k *.>: a CC en cx in 0£P 56 substantial (more than 20). Seek tine can be computed from distance with fair accuracy as long as the function is nearly linear and the effect of the zero distance seeks can be estimated or ignored. Again, in all but the FIFO policy, improvement in average seek distance is observed as bulk size increases at constant arrival intensity, due to increased scheduling freedom. For the three non- inter jec ting policies, FIFO, MSCAN, and SBF, average seek distance does not vary with arrival intensity. The SCAN policy shows marked reduction in average seek distance as arrival intensity grows while for the PSBF policy only a slight increase in average seek distance is observed for small bulks at high arrival intensity. This odd behavior is apparently a result of "arm stealing", in which a preempting bulk carries the arm off to some distance from its location at the time of preemption while servicing its needs. Both the seek time and latency time are quite insensitive to the suppressed variable, 6 , in Figures 3.4, 3.5, and 3.6. Graphs for the other values of 6 (0.25, 1, and 2) are only minuscully different from those shown. Simula t ion Conclusions The simulations have shown that the choice of scheduling algorithm does affect the overall performance of disk and drum systems. To compare a range of cases we make point by point comparisons and weight the results to produce an overall comparison. Except in the rare circumstance where one algorithm 57 is consistently better than another the weights ve select often determine the outcome. Tables 3.2a-3.5b illustrate one approach to comparison using equal weights. We first produce the precedence matrices shown in Tables 3- 2a- 3- 2c. For each measure ve compare all cases for all possible pairs of scheduling algorithms. The results are the table entries, where > means that the algorithm heading the row is better than the algorithm heading the column. A < means the converse, - means the two algorithms are equivalent for the performance measure, and ? means no comparison could be made because neither algorithm was stable under the conditions. One algorithm is judged better than another with respect to a performance measure if the mean value of the performance measure for the first algorithm exceeds the mean value of the other algorithm's performance measure by more than the maximum of the confidence levels of the measures. If the difference between the means is less than the maximum of the confidence levels they are judged equivalent. A stable algorithm is always judged better than an unstable one. To compare over a range of cases we assign points to the outcome of these pair wise comparisons as follows. A victory (>) is worth 2 points to the victor, a tie (=) is worth 1 point to each algorithm, and a loss (<) is worth points to the loser. A ? is not counted, as are the other three possiblities, in determining points or number of comparisons. Summing scores over a number of cases gives an equal-weighted two part result 58 consisting of the total score for the algorithm and the number of valid comparisons scored. Tables 3.3a-3.5b show the results of such comparisons for both disk and drum where each of the three pairs of 6, i, and g where summed over. In Appendix C all the possible combinations in which only one variable was summed out are given. Por example, in Table 3.3a for a drum with 6=1.00, summing over all i and g values to leave the scores as a function of only 6, we find SBF and MSCAN in a virtual tie with 185 and 184 points for core usage. PSBF, FIFO, and SCAB follow in order. Looking up and down the values of 6 one can observe how it changes the comparison of the algorithms on the basis of core usage results. For example one can see that as 6 increases FIFO improves relative to SCAN and PSBF. 59 Disk 6=0.50 g=20 Request Service Time i=.05 i=.15 i=.25 i=.35 i=.U5 i=.55 FIFO MSCAN SCAN SBF PSBF FIPO s < < < < 1 MSCAN > — = s SB 1 SCAN > ss = sss SS 1 SBF > = = SB SS 1 PSBF > 3S ss = S5 FIFO MSCAN SCAN SBF PSBF FIFO = < < < < 1 MS CAN > ss < = ss 4 SCAN > > ss > > 1 SBF > ss < ss =s 1 PSBF > ss < ss = FIFO MSCAN SCAN SBF PSBF FIFO = < < < < 1 MSCAN > = < ss = n SCAN > > ss > > 1 SBF > = < = -= 1 PSBF > = < = == FIFO MSCAN SCAN SBF PSBF FIFO = < < < < 2 MSCAN > = < = > n SCAN > > = > > 2 SBF > = < = > 1 PSBF > < < < ss FIFO MSCAN SCAN SBF PSBF FIFO j < < < < 2 MSCAN > = < — > a SCAN > > ss > > 2 SBF > ss < SB > 1 PSBF > < < < ss FIFO MSCAN SCAN SBF PSBF FIFO 7 < < < < 2 MSCAN > = < = > a SCAN > > = > > 2 SBF > = < = > 1 PSBF > < < < = Sample Algorithm Precedence Matrix for Mean of Request Service Time Table 3.2a 60 Disk 6=0.50 g=20 Bulk Service Time i=-05 FIPO HSCAN SCAN SBP PSBP FIPO 3C < < < < 1 HSCAN > = s ■ = 1 SCAN > = s * ■ 1 SBF > = 3= * ■ 1 PSBP > s * * = i=.15 PIPO HSCAN SCAN SBP PSBP FIPO = < < < < 1 HSCAN > = s ■ < 1 SCAN > = = < < 2 SBP > = > ■ < PSBF > > > > ■ i=-25 PIPO HSCAN SCAN SBF PSBF FIPO ■ < < < < 1 HSCAN > = ss = < 1 SCAN > = s < < 2 SBP > = > s < a PSBP > > > > = i=.35 FIFO HSCAN SCAN SBF PSBP FIFO = < < < < 1 HSCAN > = = s < 1 SCAN > = = < < 2 SBF > = > = < U PSBF > > > > X i=.45 FIPO HSCAN SCAN SBP PSBP FIFO 7 < < < < 1 HSCAN > = = = < 1 SCAN > = = < < 2 SBF > = > = ■= 3 PSBF > > > = ■ i=.55 PIFO HSCAN SCAN SBF PSBP FIPO ? < < < < 1 HSCAN > = ■= SB < 1 SCAN > = = < < 2 SBP > = > = = 3 PSBF > > > ss = Sample Algorithm Precedence Hatriz for flean of Balk Service Tiire Table 3.2b 61 Disk 6=0.50 g=20 i=-05 i=.15 i=.25 i=.35 i=.U5 i=.55 Core Osa ge FIFO MSCAN SCAN SBF PSBF FIFO as < < < < 1 MSCAN > as = as as 1 SCAN > = s as as 1 SBF > = as as 3 1 PSBF > — as SS — FIFO MSCAN SCAN SBF PSBF FIFO 3 < < < < 2 MSCAN > = > 3 as 1 SCAN > < as < as 2 SBF > = > as 3 1 PSBF > as as s as FIFO MSCAN SCAN SBF PSBF FIFO = < BE < < 2 MSCAN > s > as 3 SCAN as < 3 < < 2 SBF > as > a: as 2 PSBF > = > 3 3 FIFO MSCAN SCAN SBF PSBF FIFO as < =s < < 3 MSCAN > = > as > SCAN — < = < < 3 SBF > as > = > 2 PSBF > < > < — FIFO MSCAN SCAN SBF PSBF FIFO ? < < < < 3 MSCAN > = > 3 > 1 SCAN > < = < < 3 SBF > = > = > 2 PSBF > < > < 3 FIFO MSCAN SCAN SBF PSBF FIFO ■> < < < < 3 MSCAN > = > — > 1 SCAN > < as < < 3 SBF > = > = > 2 PSBF > < > < 3 Sample Algorithm Precedence Matrix for Mean of Core Usage Table 3.2c 62 Drum 6 = 0.25 g- * i= * Drum 6=0.50 q= * Drum 6=1.00 g= * i= * Drum 6=2.00 g= * i= * Bequest Service PIPO 120 NSCAN 128 120 SCAN 217 120 SBP 128 120 PSBP 127 120 Request Service *IFO 120 HSCAN 127 120 SCAN 218 120 SBP 127 120 PSBP 128 120 Request Service PIPO 120 NSCAN 127 120 SCAN 221 120 SBP 128 120 PSBP 124 120 Request Service PIPO 88 NSCAN 90 88 SCAN 174 96 SBP 96 90 PSBP 90 88 Bulk Service PIPO 120 HSCAN 136 120 SCAN 140 120 SBP 142 120 PSBP 182 120 Bulk Service PIPO 120 NSCAN 134 120 SCAN 115 120 SBP 144 120 PSBP 207 12 Bulk Service PIPO 120 HSCAN 130 120 SCAN 93 120 SBP 158 120 PSBP 219 120 Bulk Service FIFO 17 88 HSCAN 82 88 SCAN 69 96 SBP 130 90 PSBP 152 88 Core Osage FIFO 25 120 HSCAN 168 120 SCAN 94 120 SBF 168 120 PSBF 145 120 Core Osage FIFO 54 120 HSCAN 176 120 SCAN 56 120 SBF 176 120 PSBP 138 120 Core Osage FIFO 88 120 HSCAN 184 120 SCAN 29 120 SBF 185 120 PSBP 114 120 Core Usage FIFO 87 88 HSCAN 122 88 SCAN 38 96 SBF 130 90 PSBF 73 88 Drum Performance Comparisons as a Function of 6 Table 3.3a. 63 Disk 6=0.25 g= * i= * Disk 6=0.50 g= * i= * Disk 6=1.00 g= * i= * Disk 6=2.00 g= * i= * Request Service FIFO 119 MSCAN 145 120 SCAN 225 120 SBF 145 120 PSBP 83 119 Request Service FIFO 115 MSCAN 139 117 SCAN 228 120 SBF 140 117 PSBF 77 115 Request Service FI FO 91 MSCAN 105 92 SCAN 200 104 SBF 100 91 PSBF 65 92 Request Service FIFO 61 MSCAN 63 61 SCAN 128 68 SBF 66 62 PSBF 57 62 Bulk Service FIFO 119 MSCAN 122 120 SCAN 126 120 SBF 161 120 PSBF 189 119 Bulk Service FIFO 115 MSCAN 119 117 SCAN 123 120 SBF 164 117 PSBF 178 115 Bulk Service FIFO 9 1 MSCAN 90 92 SCAN 108 104 SBF 117 91 PSBF 155 92 Bulk Service FIFO 2 6 1 MSCAN 54 61 SCAN 65 68 SBF 83 62 PSBF 110 62 Core Usage FIFO 28 119 MSCAN 192 120 SCAN 71 120 SBF 192 120 PSBF 115 119 Core Usage FIFO 26 115 MSCAN 185 117 SCAN 74 120 SBF 188 117 PSBF 111 115 Core Usage FIFO 39 91 MSCAN 141 92 SCAN 75 104 SBF 133 91 PSBF 82 92 Core Usage FIFO 44 61 MSCAN 86 61 SCAN 35 68 SBF 94 62 PSBF 55 62 Disk Performance Comparisons as a Function of 6 Table 3. 3b. 64 Drum Request Ser vice Bulk Service Core Osage 6= * PIPO 89 FIFO 4 89 FIFO 103 89 g= 2 HSCAN 97 89 HSCAN 78 89 HSCAN 123 89 i= * SCAN 156 92 SCAN 120 92 SCAN 39 92 SBP 98 89 SBF 106 89 SBF 123 89 PSBF 97 89 PSBF 140 89 PSBF 60 89 Drum Bequest Service Bulk Service Core Osage 6= * PIPO 89 FIFO 3 89 FIFO 54 89 g= 5 HSCAN 92 89 HSCAN 95 89 HSCAN 130 89 i= * SCAN 172 92 SCAN 96 92 SCAN 44 92 SBP 92 89 SBF 111 89 SBF 130 89 PSBF 92 89 PSBF 143 89 PSBF 90 89 Drum Request Service Bulk Service Core Osage 6= * PIPO 92 FIFO 3 92 FIFO 38 92 g=10 HSCAN 96 92 HSCAN 100 92 HSCAN 142 92 i= * SCAN 172 92 SCAN 77 92 SCAN 36 92 SBP 96 92 SBF 121 92 SBF 142 92 PSBP 96 92 PSBF 159 92 PSBF 102 92 Drum Request Service Bulk Service Core Usage 6= * PIPO 92 FIFO 4 92 FIFO 38 92 g=20 HSCAN 98 92 HSCAN 107 92 HSCAN 129 92 i= * SCAN 166 92 SCAN 69 92 SCAN 52 92 SBP 98 92 SBF 119 92 SBF 130 92 PSBP 98 92 PSBF 161 92 PSBF 111 92 Drum Request Service Bulk Service Core Usage 6= * PIPO 86 FIFO 3 86 FIFO 21 86 g=50 HSCAN 89 86 HSCAN 102 86 HSCAN 126 86 i= * SCAN 164 88 SCAN 55 86 SCAN 46 88 SBP 95 88 SBF 117 88 SBF 134 88 PSBP 86 86 PSBF 157 86 PSBF 107 86 Drum Performance Comparisons as a Function of g Table 3.4a. 65 Disk Request Service Bulk Service Core Osage 6= * FIFO 73 FIFO 2 73 FIFO 59 73 g= 2 HSCAN 87 74 HSCAN 67 74 HSCAN 114 74 i= * SCAN 148 80 SCAN 122 80 SCAN 51 80 SBF 88 74 SBF 97 74 SBF 114 74 PSBF 51 73 PSBF 86 73 PSBF 36 73 Disk Request Service Bulk Service • Core Usage 6= ♦ FIFO 76 FIFO 76 FIFO 31 76 9= 5 MSCAN 92 77 HSCAN 72 77 MSCAN 124 77 i= * SCAN 154 80 SCAN 86 80 SCAN 42 80 SBF 92 77 SBF 110 77 SBF 124 77 PSBF 48 76 PSBF 118 76 PSBF 65 76 Disk Request Service Bulk Service Core Usage 6= * FIFO 82 FIFO 82 FIFO 25 82 g=10 HSCAN 98 82 HSCAN 76 82 HSCAN 131 82 i= * SCAN 166 88 SCAN 80 88 SCAN 49 88 SBF 97 82 SBF 116 82 SBF 131 82 PSBF 55 82 PSBF 144 82 PSBF 80 82 Disk Request Service Bulk Service Core Usaqe 6= * FIFO 82 FIFO 82 FIFO 17 82 g=20 MSCAN 92 82 HSCAN 85 82 HSCAN 121 82 i= * SCAN 164 88 SCAN 80 88 SCAN 62 88 SBF 91 82 SBF 106 82 SBF 121 82 PSBF 69 82 PSBF 145 82 PSBF 95 82 Disk Request Service Bulk Service Core Usage 6= * FIFO 73 FIFO 73 FIFO 5 73 g=50 MSCAN 83 75 MSCAN 85 75 HSCAN 114 75 i= * SCAN 149 76 SCAN 54 76 SCAN 51 76 SBF 83 75 SBF 96 75 SBF 117 75 PSBF 59 75 PSBF 139 75 PSBF 87 75 Disk Performance Comparisons as a Function of g Table 3.4b. 66 Drum Request Serv ice Bulk Service Core Osage 6= * FIFO 80 FIFO 80 FIFO 33 80 9= * HSCAM 100 80 MSCAN 101 80 MSCAN 96 80 i=-05 SCAN 100 80 SCAN 90 80 SCAN 81 80 SBF 100 80 SBF 103 80 SBF 96 80 PSBF 100 80 PSBF 106 80 PSBF 94 80 Drum Request Service Bulk Service Core Usage 6= * FIFO 80 FIFO 5 80 FIFO 40 80 g= * MSCAN 86 80 MSCAN 94 80 HSCAN 110 80 i=.15 SCAN 142 80 SCAN 69 80 SCAN 45 80 SBF 86 80 SBF 98 80 SBF 110 80 PSBF 86 80 PSBF 134 80 PSBF 95 80 Drum Request Service Bulk Service Core Usage 6= * FIFO 80 FIFO 7 80 FIFO 52 80 g= * HSCAN 81 80 MSCAN 85 80 HSCAN 121 80 i=.25 SCAN 156 80 SCAN 62 80 SCAN 25 80 SBF 82 80 SBF 104 80 SBF 121 80 PSBF 81 80 PSBF 142 80 PSBF 81 80 Drum Request Service Bulk Service Core Usage 5= ♦ FIFO 78 FIFO 5 78 FIFO 55 78 g- * MSCAN 76 78 HSCAN 76 78 HSCAN 117 78 i=.35 SCAN 160 80 SCAN 68 80 SCAN 23 80 SBF 82 80 SBF 107 80 SBF 125 80 PSBF 76 78 PSBF 138 78 PSBF 74 78 Drum Request Service Bulk Service Core Usage 6= * FIFO 70 FIFO 70 FIFO 34 70 g= * MSCAN 68 70 MSCAN 69 70 HSCAN 111 70 i=-45 SCAN 152 76 SCAN 73 76 SCAN 32 76 SBF 68 70 SBF 87 70 SBF 111 70 PSBF 68 70 PSBF 127 70 PSBF 66 70 Drum Request Service Bulk Service Core Usage 6= * FIFO 60 FIFO 60 FIFO 40 60 g= * MSCAN 61 60 MSCAN 57 60 HSCAN 95 60 i=. 55 SCAN 120 60 SCAN 55 60 SCAN 11 60 SBF 61 60 SBF 75 60 SBF 96 60 PSBF 58 60 PSBF 113 60 PSBF 58 60 Drum Performance Comparisons as a Function of i Table 3.5a. 67 Disk Request Service Bulk Service Core Osage 6= * PIPO 80 FIFO 80 FIFO 14 80 g= * MSCAN 95 80 MSCAN 96 80 MSCAN 102 80 i=.05 SCAN 117 80 SCAN 87 80 SCAN 86 80 SBF 95 80 SBF 101 80 SBF 103 80 PSBF 93 80 PSBF 116 80 PSBF 95 80 Disk Bequest Service Bulk Service Core Usage 6= * PIFO 80 FIFO 1 80 FIFO 33 80 g= * MSCAN 87 80 MSCAN 89 80 MSCAN 127 80 i=.15 SCAN 160 80 SCAN 64 80 SCAN 34 80 SBF 87 80 SBF 102 80 SBF 127 80 PSBF 66 80 PSBF 144 80 PSBF 79 80 Disk Request Service Bulk Service Core Usage 6= * FIFO 79 FIFO 1 79 FIFO 45 79 g= * MSCAN 91 79 MSCAN 72 79 MSCAN 125 79 i=.25 SCAN 160 80 SCAN 70 80 SCAN 22 80 SBF 95 80 SBF 110 80 SBF 132 80 PSBF 52 80 PSBF 145 80 PSBF 74 80 Disk Request Service Bulk Service Core Usage 6= * FIFO 61 FIFO 61 FIFO 34 61 g= * MSCAN 74 62 MSCAN 54 62 MSCAN 105 62 i=. 35 SCAN 136 68 SCAN 74 68 SCAN 30 68 SBF 69 61 SBF 81 61 SBF 97 61 PSBF 35 62 PSBF 105 62 PSBF 48 62 Disk Request Service Bulk Service Core Usage 6= * FIFO 50 FIFO 50 FIFO 11 50 g= * MSCAN 60 50 MSCAN 40 5C MSCAN 83 50 i=.45 SCAN 112 56 SCAN 63 56 SCAN 35 56 SBF 60 50 SBF 73 50 SBF 84 50 PSBF 24 50 PSBF 80 50 PSBF 43 50 Disk Request Service Bulk Service Core Usage 6= * FIFO 36 FIFO 36 FIFO 36 g= * MSCAN 45 39 MSCAN 34 39 MSCAN 62 39 i=.55 SCAN 96 48 SCAN 64 48 SCAN 48 48 SBF 45 39 SBF 58 39 SBF 64 39 PSBF 12 36 PSBF 42 36 PSBF 24 36 Disk Performance Comparisons as a Function of i Table 3.5b. 68 Figures 3. 7a- 3. 8c illustrate the relative performance of the algorithms Cor g=20 and 6=0.50 for both the drum and disk. Figure 3.7a demonstrates the typical ordering of the algorithms in terms of bulk service time. Note how closely bunched all curves but the one for FIFO are. For the droa configuration PSBF provides the best bulk service time while SCAN, due to bulk interleaving, is outperformed by MSCAN and SEF in addition to PSBF. Figure 3.7b confirms that any difference in bulk service time of SCAN, MSCAN, SBF and PSBF must be due to ordering of reguests and not the individual reguest service times, which are virtually identical. Figure 3.7c clearly illustrates the linear growth of core usage of FIFO, MSCAN and SBF. Note that HSCAN and SBF produce identical core usage since they process individual bulks in an identical manner. PSBF and SCAN show greater than linear growth in core usage with arrival intensity. SCAN grows faster than PSBF because interleaving is common under SCAN but occurs only during preemptions in PSBF. Notice that core usage for SCAN actually exceeds that of FIFO at high arrival intensities. Figures 3.8a-3.8c demonstrate the relative behavior for a disk system with g=20 and 6=0.50 for differing scheduling policies. As in the drum case (Figure 3.7a) all but FIFO have closely bunched bulk service times. PSBF has the smallest bulk service time while SCAN begins to outperform MSCAN at large arrival intensities due to the reduction in reguest service time overcoming the interleaving effect of SCAN. The decrease in request service time for SCAN compared to HSCAN, SBF, and PSBF is 69 y aim in ?S tin o_ CD CYJ CD O IT LU 8 HI cr > o CC met H in in o o o o 0^05 O'Oh 0'0£ 0'0£ 3WF1 33rAU3S Min9 001 0° 70 21 ID CD CD 5 u ! 1 1 i 1 - *) • i *# ; 1 N) i i 1 -■ 1 1 1 f » 1 H- + _;>- $ UJ on cr > •—i r>cr 4. 3 ••4 » 9 M Q i A u r» o • J 2 K 9 iS 5 4-> •I D If) in 05 e OO'd OS'l 00* 1 OS'O 3NT1 3DTAH3S !S3nD3ld o S oo-oP 71 QZ / \ O CD 5'L i S + 0'9 1_ s'h ire 39t/sn 3yoo 51 § s D tn en » . z . ° _j o ■ cr "» 6 9 M U 19 o ID o ocP 72 CO I 1 / s CO C\J o C\J CD 0"S + -I- H !* -I- § $ s 4 4J en LJJ u • inh- o«n o JjJ — I •* w CE K-H > * IS s o Oh O'E. 0"2 01 [ eOIXJ 3Wn 3DTAH3S Mlfl8 o : o° 73 CD o CYJ C\J CD •-i u. <°.>: «)! *.>! » lift,: ity I IH = ;< *3? llll •if M D en LU Lfl cr .(ncr IS •H a • U 09 o • is •H 9 H 9 « * M • m en in + + ose 00 'I OS' l 00 "1 OS'O 3WI1 33TAH3S lS3nQ3U 00 '0° 7<» CO CD on CYJ o CYJ CD Q'OZ 0Ti£ t i + 4- 081 0£1 39USD 3UQD 0'9 § $ z u LU *• I— • • Z o O Mb _j O 5 *•? > • ft. 9 K of s °' 8 O U IS a in & of 75 shown in Figure 3.8b. Core usage in Figure 3.8c shovs that once more SBF and HSCAN have identical behavior. SCAM and PSBF again display greater than linear growth with arrival intensity. SCAR core usage exceeds that of FIFO for larger arrival intensities. However in this case the break from linear growth in FIFO core usage is due to system saturation. It is unfair to say SCAN is worse than FIFO in this region where FIFO is unable to handle the load. From the sample curves we can see that the most sensitive performance measure, core usage, varies 50% between the best and worst algorithms, excluding FIFO, for drums. For disks a factor of 2.5 separates SCAN and HSCAN or SBF for core usage at the highest arrival intensity simulated. Differences in bulk service time for the four reasonable algorithms (SCAN, HSCAN, SBF, and PSBF) amount to a factor of 2 for disks and 40% for drums. In large systems differences of these magnitudes can have spectacular effects on overall system performance. 76 Chapter 4 ANALYTICAL STUDIES In this chapter the mean and variance of the request service time, bulk service time, and core occupancy are derived analytically for the scheduling algorithms studied in this thesis. Results on queue length and 90S points are determined whenever possible. Nota tion and Q ueueing Theory Following the notation in Kleinrock [32] we define two generic random variables t = interarrival time x = service time Associated with each of these random variable is a cumulative probability distribution, or CDF, of the form A(t) = Prob1 the work piles up faster than it can be handled and the queue grows without bound. An important result relating N and T in stable systems ( p <1) is Little* s result N = XT This result requires no assumptions on the nature of a(t) or b(x) and can be applied to different portions of the queueing system if proper definitions for N, X, and T are observed. The one-sided Laplace transform of f(t), denoted oo - s t F*(s) = / f(t)e dt will be required in some of our work. The z-transform of a function g (x) , where x is drawn from the non-negative integers, will also appear occassionally and is defined as 00 G(z) = I g(x)z x=0 Hsvie* 2l Assum ptions As discussed in Chapter 2, we assume that the arrival of bulks of secondary storage access requests is a Poisson process with average arrival rate X- Following the convention that the probability density function (PDF) of a continuous random variable is denoted by a lower case letter and its associated cumulative distribution function (CDF) by the corresponding upper case letter, for the arrival process, we have 81 -Xt a(t) = Xe t > (PDF) (4.1a) -Xt A(t) - 1-e t > (CDP) (4.1b) The expected value of a random variable x is represented as B[ x ] 2 2 2 or x. The variance of x, a , can be computed as E[ x ]-E[ x ] .. x For our arrival distribution, letting t be the interarrival time of the bulks E[t] - 1/X (4.2a) 2 2 a = 1/X or a = 1/X (4.2b) t t The number of secondary storage access requests, k, in a bulk is assumed to be geometrically distributed with expected value g. It is easy to show that k g = Prob(bulk contains k members) * _J_ f StzJJ (4.3a) 5^ \\) E[kJ - g (4.3b) 2 c = (g-1)g (4.3c) k Requests are assumed to be uniformly distributed over the device. Hence for the cylinder addresses of a device with n cylinders Prob (request lies on cylinder i) = 1/n i=1,2,3...,n The rotational position, 8 , of the start of each request is assumed to be uniform over the rotational period of the device, so that r (0) = 1 < 9 < 1 (4.4a) 82 P(6) = e (4.4b) The record length, x, is assumed to be exponentially distributed with mean -x/6 l(x) = e x > C».5a) 6 -x/6 L(x) = 1-e (4.5b) 2 2 o = 6 or o = 6 (*»-5c) X X The final major assumption is that the seek time of the disk is a linear function of the distance travelled for non-zero distances. Hence we have t (d) = if d=0 (4.6) s = \\> d+ij; if d=1,2,3... n-1 1 The request service time, t , is defined as the sum of the r transfer time, t , the rotational latency tiwe, t , and the seek time, t , or s t ■ t ♦ t ♦ t (4.7) r t 1 s The bulk service time is more correctly the bulk system time; the total queueing and service delay experienced by a bulk- If we define w = nin(i ,w ,w ,...,w ) (4.8a) f 12 3 n W = max(W ,W ,w , ,tf ) (4.8b) 1 12 3 n 83 where W. is the gueueing time of the i member of the bulk, then obviously we can define the bulk service time, T, as T = t ♦ W (4.9) If we define t - time at which request i of bulk j begins service ij x = service time of request i of bulk j ij 1 = buffer space used by ceguest i of bulk j ij n ■ number of requests in bulk j j then we can define the mean buffer occupancy, or core usage, as n C = lim I I 1 (t *x -t ) „->• -j =1 i=s1 ± j n j n j ij j 1 t +x n w n w w w This is the amount of buffer space used times the time it is in use divided by the total elapsed time. l2HQ^s on P erformance of Drum and D isk System s He note again, Eq. (4.7) , that there are three components of the reguest service time: seek time, rotational latency, and transfer time. The seek time and rotational latency are overhead in the access times of the disk and drum systems under consideration. Clearly, to minimize reguest service time we 84 should strive to reduce or eliminate seek and rotation time. In the limiting case request service time consists of only the Poisson distributed transfer time. Hence transfer time represents a lower bound on the request service time. In this case the model of the storage system simplifies from an H/G/1 system to M[x]/H/1 in Kendall's notation. Let p be the probability that the systenr has k customers and y be the mean service rate. By inspection, the steady state Chapman- Kolmogorov equations for the system are k-1 = -(X*y)p *pp *X I p q k>1 (4. 11a) k k+1 i=0 i k-i = -Xp ♦ yp (4.11b) 1 Using z-transforms we may convert the last set of equations to the equivalent form = -XP(z)-y[P(z)-p ]*y[P(z)-p ]/z*XG(z)P(z) (4.12) Solving for P(z) we have P(z) = yp0(1-z) (4.13) y(1-z)-Xz(1-G(z)) p ■ 1-p and p= B[x]/y (4-14) G (z) = z( 1-ct) (4.15) 1-az where a- (g-1)/g and E[ x ] ■ G«(1) ■ 9 To find the average queue length we evaluate P* (1) and obtain 2 L = P* (1) = X6q = g.Q (4.16) q 1-X6g 1-p 85 For the special case of g*1 we get the B/H/1 result as expected (observe that o£*0, all bulks are of siie one in this case). The bulk service time, T, which is simply the average request service time times the sum of the average number of requests in the queue and the average bulk site T = 6(1 *g) (U. 17a) g ~ q O 02 UJ u_ en cr oz + +■ 0"S I Oh O'E 0*2 I eOIXI 3NT1 3DTAU3S H1D0 + oat o 33. Ln If •>- cm o en en a: > «— • enct o D a) in o in D O'fl p 87 o 1 \ D CD CC LU U_ CO 3 9! § Ln D It '»- C? LU ? 14 IM 9 • M J) E£ n en _J cr > ►— ■ • o QC o in 3» ! i- u M m u 9 o> -H CE Lfl LP a O'S + + + + Oh O'L 0'2 D"l I 2 01XI 3WT1 33fAH3S vnng TtP 88 Q J CD p O LU en 4- O'S Oh OX l eO IX) 3WU D'2 3DTAU3S wim Si! in ru Lfl in u en UJ r- Ct > en CX u in e g . CD U U • l" « J a • 9* ■ "4 ■H h, H S •H » V) u D in o 8 89 o CO K" > o LU CD CE O'Sl I eOUl 3NTL D'9 33TAU3S DC mna O'fT 90 2 2 2 A6 q = X6t g (U. 20) r Z1ZQ. Analysis He are now ready to begin our analysis of scheduling policies- The analysis of the FIFO algorithm, first for the drum and then for the disk, provides an example of the general method of attack- The components of the reguest service time, that is seek time (disk only) , rotational latency time, and transfer time, are determined and combined. Using the service policy and request service time, the core occupancy is computed- Then, whenever possible, request service times are combined using bulk size distributions to produce super-custoners in an M/G/1 queueing model. With the bulk arrival distribution the bulk service time can be determined, along with queue length in requests and average bulks- FIFO Policy, for Drum System Since FIFO does not disturb the natural order of the bulks or the requests they contain, the expected value and variance of the latency time are given by t = 1/2 (4.21a) 1 2 a = 1/12 (4.21b) 1 The request service time is just the sum of the rotational 91 latency and the transfer tine, since, by our undisturbed initial assumptions, these random variables are statistically independent, we have t » t ♦ t * 5 ♦ 1/2 (4.22a) r t 1 2 2 2 2 a^o+o^S* 1/12 r t 1 (4.22b) Recalling that x is the random variable representing the service time distribution and that, in FIFO, all requests are statistically independent, ve can immediately say x = gt ■ g (6*1/2) r (4.23a) 2 2 2 2 2 2 a - ga *(t ) a « g(5 *1/12) ♦ (6*1/2) (g-1)g (4.23b) x r r g where ve have chosen the service time to be that of a whole bulk. The traffic intensity is p = Xx = Xg(6*1/2) (4.24) With the mean and variance of service time as defined for the M/(3/1 queueing system ve can apply the Pollaczek-Khinchin mean value formula T = 2 2 X ( a ♦ x ) 1 ♦ __* 2x(1-p) (4.25) After substitution of our equations for the terms of Eq. (4.25) ve arrive at the following expression for the bulk service time T = 1 ♦ X(6 +izi2»(?q-i) (n-1)/n 1 2 n-1 2 *[t ] = I p(d)t(d) s d=0 2 2 2 2 88 ^ (n -1)/6 ♦ 2iJj i> (n -1)/3n ♦ ty (n-1)/n 1 10 2 2 2 2 2 2 a - jjl ( n -1) (n »2) ♦ 2^1 ^Ofn -1) ♦ 4 *0 (n-1 ) (4.31) s 2 2 2 18n 3n n Since the FIPO algorithm does not disturb the independence 94 assumptions of the stream of input requests, we can compute the request service time mean and variance as the sum of independent random variables. The transfer time and rotational latency are the same as for the drum. Combining them ve find t = t t t ♦ t r t 1 s 2 2 2 2 a = a ♦a ♦ a r t 1 s x = gt (4.32a) (4.32b) (4.33a) 2 2 2 a = 'go ♦ (t ) (g-1)g x r r p - Ax (4.33b) Combining terms and substituting into Eq. service time, T, we ha?e (4.25) for the bulk T = 1 ♦ (4.34) Forward substituting into the last equation only obscures the result. The core usage follows just as in the drum case 2 c = A6t g r (4.35) MSCAN A nalysis In the MSCAN policy the requests comprising each bulk are reordered to reduce seek and latency time but the bulks themselves are served in first-come-first- served order. In terms 95 of the R/6/1 queueing system each balk represents a super- customer with a general service time distribution. This distribution is the sum of seek times (disks only) , rotational latency times, and transfer times for all the requests of the bulk. Once the mean and variance of the service time of each super-customer is determined the bulk service time can be found from the Pollaczek-Khinchin mean value formula since the super— customers are serviced PIPO. BSCAN Eolicy for Drum Systems The mean and variance of the transfer time remain unchanged. For the mean and variance of the total transfer time we determine the sum of a random number of identically distributed statistically independent random variables and obtain t = g6 (4. 36a) tt 2 2 2 a = g 6 (4.36b) tt To determine the total latency ve must consider hov HSCiM schedules requests which lie on the same cylinder and belong to the same bulk. In this case H5CAN uses the SLF policy, which requires that whenever the head becomes free it selects the nearest request next. Since the distribution of the rotational position of requests is a statistically independent random variable uniform over [0,1), the latency distribution for the initial request selected is that of a minimum of n samples of the 96 random variable. If the distribution of the transfer time were such that the position of the head upon completion of a transfer were independent of it starting position, this approach could be repeated iteratively for the remaining n-1 requests. However, the only continuous distribution which destroys knowledge of its starting position completely is uniform modulo 1. For any other distribution the total latency will not be independent of all the record positions and lengths. Assuming the independence assumptions were met, the mean and variance of n independent samples would be t = JL. (4.37a) In n*1 2 a = n (4.37b) In 2 (n*1) (n*2) For the bulk size distribution assumed the mean and variance of the total latency are oo n t = [p 7 _i_ (4.38a) It n=1 n i=1 i*1 = 3— 1 ♦ g(ln(g)-1) 2 (g-D 2 « 2 «> 2 a = I a p ♦ I (t -t ) p (4.38b) tl n=1 In n n=1 In It n As was noted, these equations are exact only if the transfer time renders the latencies independent. It can be shown that as increases the transfer time distribution assured here approaches a uniform distribution modulo 1. Taking Eg. (4.38a) as an 97 approximation for our values of 6, the following table shois the accuracy obtained. 10 20 50 Analytic latency Simulated latency Percent error .586" .253 .173 .113 • 061 .382 .263 .194 .146 .095 0.2 3.8 10.8 22.6 35.8 MSCAN Latency Approximation Table 4.2. The independence assumption is not a bad approximation for all but the largest bulk size simulated. Combining the means and variances of the total latency and total transfer time to obtain the mean and variance of the time to service each bulk, ve obtain x - g6 ♦ o__ [l ♦ g(ln(g)-1)J (4.39a) (g-D 2 2 2 2 a = g 6 ♦ a (4.39b) x It These values can be substituted into Eq. (4-25) to find T, the MSCAN bulk service time. Core usage can be immediately computed as was done in FIFO to show C = Xg6x (4.40) MSCAN Policy for Disk Systems To solve for the average bulk service time for the MSCAN policy applied to a disk system ve must determine the seek, latency, and transfer contributions that sum to produce the service time of a bulk. First ve find the Bean and variance of 98 the total distance the head must move to service the entire bulk, ignoring initial positioning, as a function of bulk size. Let us use a continuous variable, x, to approximate the quantized cylinder position number, v=1 ,2,3,. •• ,n. Clearly 2 Prob(min(x ,x ,x ,...,x ) y PDF = CDF * dx k-1 k - Mx-y) /(1-y) *y (4.U3) By integrating this last PDF over x and y we can determine the moments of (x-y) and obtain the mean and variance of the total seek distance ve desire .2 F[ (x-y) |k requests] = W 2 .2 a = d (h " (** 1 ) (a.uaa) (U.uub) He now have the seek distance but what we need is the seek time. 99 To determine this ve must know not only how far the head moves but hov many stops it makes. This is the problem of placing g distinct balls into n urns such that exactly k urns are non-empty. With requests taking the place of balls and cylinders the place of urns ve can immediately vrite k S n! Prob (require k stops to read g * g (4.45) requests from n cylinder disk) g n (n-k) ! The mean and variance of the number of stops are E[# stops] = I _I_&zil I * i=1 g-1 \g J k-1 2 2 2 a = E[ stops ] - £[ stops] (4.46b) s Obviously ve could nov concern ourselves with the total latency given that ve make k stops, since k and g tell us hov many cylinders could have multiple requests. Instead ve assume no tvo requests lie on the same cylinder. This approximation should be good for small q, since Prob (no 2 of g requests lie on nj. same one of n cylinders) =* g (4.47a) n (n-g) ! -g ■ e /2 7rn/ (n-g) (4.47b) The total seek time mean and variance vould then be 2 st 1 lg+ll (4.48a) 100 2 2 2 a = \p n st 1 («^ " rV (4.48b) Since ve assumed that no two requests vere for the sane cylinder ve have the following foe the total latency t * g/2 (4.49a) It a = g(3g-2)/12 It (4.49b) The total transfer time is unchanged, so ve have t * 6g tt 2 2 2 a - g 6 tt (4.50a) (4.50b) By our independence assumptions ve can sum the transfer, seek, and latency time to get i » t ♦ t «• t tt st It 2 2 2 2 a = a ♦ a ♦ a x tt st It (4.51a) (4.51b) At this point ve have the necessary terms to substitute into the Pollaczek-Khinchen mean value formula to find T f the bulk service time for HSCAN disk. Using the nev definition for i, the core usage expression is unchanged. 101 SBF Polic y for Drum and Disk S ystems The SBF discipline can be analyzed using the technique in Conway et al [33]. This technique does require the assumption that service of requests in the same priority class be PIFO rather than by minimum total record length as we assumed in Chapter 2. The effect of this change should be slight. Using the same M/G/1 formulation as HSCAN and identifying all requests of one bulk as a super customer for this analysis, let us assign =*11 LuIks of size k to priority class k. Classes are assigned indexes in reverse order of priority; class 1 is the highest priority. Se define A = arrival rate of jobs of class k k x = random variable for service time of class k k p = X x = utilization factor for jobs of class k k k k Now each class can be viewed as a separate M/G/1 system with arrival rate k and service time x^. Customers in class k can only be effected by customers of higher priority (classes < k) • From our definitions it is clear that for the drum system k X = Xq = X _1_ qz^ (4.52) k k g-1 g k x = k6 ♦ I _J_ (4.53a) k i=1 i+1 2 2k a = k6 ♦ I 1 (4.53b) k i=1 (k+1) (k*2) 102 2 2 a ♦ 7 k k k k g-1 [ g / k« ♦ I -1. i*1 i*1 (4.54) (4.55) He can now us Convay's result to give the waiting time for customers of class k in terms of known quantities 2 I X x « = i~l_i_A k k-1 k 2(1- I P ) (1- I p ) i=1 i i=1 i (4.56) Immediately we have that T k , the bulk service time for bulks of size k is T = x ♦ V C*-57) k k k Since only the order in which bulks are serviced is effected by sbf, the results from HSCAN for request service time and core usage apply immediately. The disk case can be handled in exactly the same manner; it is only necessary to substitute the equations from the HSCAN disk analysis to show that in this case k 2 x = k6 k ♦ k/2 ♦ \\> n/ k \ ♦ \p k 1 \k*l] 2 2 2 2 r 2 X U - k6 ♦ k/12 + ty n Lk_\ - ( k_\ k 1 Hg*2j ^g*1 (4.58a) ♦ * 9(9-1) (4.58b) Once again the request service time and core usage are the same as for the hscan disk case. For both drum and disk the mean bulk 103 service time, T, can be computed by T - J, 1_ (gzM T (4.59) i=1 g-1 ^g / i PSDP Policy for Drum and Disk Systems The analysis of PSBP parallels that of SBF with the additional complication of preemption. By our definition preemption can occur only between requests of a bulk. Por the drum case this clearly makes the rule preemptive resume, since no cost is incured due to the interruption at such points. Por the disk case where the arm may be carried off to satisfy the requests of the preempting customer, the situation is less clear. However, for simplicity we assume preemptive resume is a sufficient approximation to actual behavior. Using the same definitions for k, x k# and p^ we can use Conway*s formuula k ~~2 x I X x T = k ♦ iz!_i_i (4.6 0) k k-1 k-1 oo k 1- I X x 2(1- I X x ) (1- I X x ) i- 1 i i i= 1 i i i=1 i i to find the bulk service time for bulks of size k. The bulk service time summed over all k and weighted is just .k T = h T = I _1_/3z1)t (4.61) i=1 i i i=1 g-1 V 9 / * The request service time should be unchanged from that of MSCAN, since individual requests are not interrupted by preemption. From Eq. (4.10) we can see that 104 C « X I 96 (<».62) i i i C = J X 5 g6 1*1 i i oo i -1 i=H g J i g SCAN RQliS.1 i2£ P£jij5 and ]>is& Systems The analyses presented to this point have hinged on being able to define a super customer in a manner such that the system can be modeled as an M/G/1 system. This has been possible because, to a first approximation, super customers so defined were independent. In the SCAN algorithm the time to service a request Is an explicit function of the number of available requests or. In other vords, the queue length. This behavior does not conform to the N/G/1 model nor the simple responsive server model, M/fl/°°. In fact, since the uunf inished vork in the SCAN system Is not conserved, even a G/G/1 model is insufficiently powerful. To illustrate the problem let us determine the request service time, conditioned on k requests in the queue, for the drum. Por the drum case, ve have the transfer time plus the latency, given k requests. Again we call on an independence assumption which ve know is only an approximation. le have t = t ♦ t » 6 ♦ J_ (4. 63a) r t 1 k*1 105 2 2 o=6* k (4.63b) r ~2 (k*1) (k*2) To solve for the queueing time we must in effect determine the probability of the queue containing k requests for all k>0. To determine these probabilities ve need the request service time but this is a function of the queue length k. He must know k to find k! With suitable numerical techniques we could obtain an approximate solution for the distribution of the queue length. However the resulting procedure would provide little additional insight into the behavior of the system not already obtained by simulation. In fact the simulation is a form of Monte Carlo solution to the above problem. Analytic Conclusions and Ins i ght s From the results in this chapter we can confirm several observations made in Chapter 3. Clearly the core usage, C, for FIFO, MSCAN, and SBF will grow linearly with arrival intensity (see Figures 3.7c and 3.8c for example) froff examination of the analytic forms for C. It is also apparent from our argument that core usage for MSCAN and SBF must be identical. Since, for a given bulk size, PSBF can only increase the time between the first and last request of a bulk, core usage for PSBF can not be less than SBF and probably will be more. 106 Table 4.3 shovs a comparison of the simulation and analytic predictions for bulk service time, request service time, and core usage. The first column of the table indicated how many times the simulation and analytic models agreed on the stability or instability of cases. For all but PSBF disk the two methods produce excellent agreement. The ratios shown for bulk service time, request service time, and core usage indicate the average value obtained by simulation over the value obtained by analysis or vice versa, such that each ratio is one or greater. This procedure produces unbiased results as neither simulated or analytic values are used as reference points. For request service time the ratio is consistently very nearly 1.000, indicating very good agreement between simulation and analysis. This close agreement vindicates the approximations that Me made in the ttSCAN, SBF, and PSBF analyses. Bulk service time also shovs good agreement except for PSBF and FIFO disk vhere results could be characterized as fair. For PSBF discrepancies are likely due to the simulation since tail effects may or may not be accurately reflected in a short simulation run. PSBF is extremely sensitive to this for bulk service time due to the discrimination against larger bulks. Core usage results are in excellent agreement except for PSBF. Hand analysis of PSBF comparisons shov simulated results are uniformly less than analytic results by about the ratio given in the table. Sensitivity to extreme cases in the simulations would seem to be ruled out as a more random relationship would be expected. A flaw in analysis or programming can not be ruled out. 107 Stabi lity Bulk Request Core predictions service service usage agree <120) time time PIFO Drum 118 1.062 1.003 1.037 FIFO Disk 116 1.306 1.003 1.040 MSCAN Drum 119 1.113 1.034 1.101 MSCAN Disk 119 1.124 1.032 1.075 SBF Drum 119 1.087 1.035 1.101 SBF Disk 115 1.145 1.041 1.062 PSBF Drum 119 1.238 1.036 1.513 PSBF Disk 110 1.331 1.048 1.645 Comparison of Simulation and Analytic Results Table 4.3. Overall the comparison of analytic and simulation results is very good. This increases confidence in both sets of results. While the analytic results are computationally superior, requiring less than two minutes of machine time to evaluate 960 cases, the twenty-one hours of simulation required for the same 960 cases did provide additional results on shapes of distributions and higher moments. Simulation was also able to handle the SCAN algorithm which proved difficult to analyze. Together they provided complementary tools for the work that was performed. 108 Chapter 5 REVIEW, CONCLUSIONS, AND SUGGESTIONS POE PUTDBE RESEARCH In this thesis the problem of scheduling accesses to a rotational storage device in the context of a timeshared information retrieval system has been defined. A model which is consistent with statistics of an operational system, MEDLINE, has been developed. Several scheduling algorithms have been proposed and measurements of their effects on system performance have been defined. Dsing the MEDLINE data, the model, and the scheduling and measurement definitions, a simulator has been designed, coded, debugged, and run to produce graphic and tabular results on the performance of the algorithms. The performance of the algorithms have been qualitatively and quantitively compared. Whenever possible the model has also been analyzed analytically. The simulation and analytic results have been compared and found in excellent overall agreement. The result of both simulation and analytic studies is that the best overall algorithm is SBF. Recall from Chapter 2 that this algorithm serves one bulk at a time, shortest bulk first. Within each bulk requests are ordered to reduce seek distance and rotational latency. SBF combines good bulk service time with lov buffer usage. PSBP provides slightly better bulk service time but exhibits greater than linear growth of buffer usage which 109 leads to unfavorable overall performance at large arrival rates. SCAN exhibits even faster buffer usage growth than PSBP and produced poor bulk service times due to excessive interleaving of requests of different bulks. HSCAN produces core usage identical to S6F but has larger bulk service time because it takes no advantage of the distribution of bulk sizes. FIFO performance is generally poor at all but the lowest arrival rates and smallest bulk sizes due to its naivete. It does outperform SCAN in terms of buffer usage under heavy loads but only until it saturates. The data collected during the simulations and the analytic expressions obtained may also be used to consider the merits of the five algorithms under other conditions or a subset of the conditions studied. The conclusions made over the whole range of conditions studied may not hold for special cases of interest. This work does provide the foundation future study in this area. The magnitude of the three performance measurements for the five scheduling algorithms differ by less than a factor of ten in all cases. However in the systems being modeled changes of less than a factor of two can dramatically effect the overall performance of the system. This is especially true in regard to the merge processor, which when poorly used can severely degrade performance as was the case in the Stellhorn multiuser simulations that sparked this work. Since the complexity of these algorithms is manageable even in a minicomputer based system there is no excuse for suffering the performance penalties imposed by an incorrect choice of access scheduling algorithm. 110 He have proved that under conditions which closely approximate an actual system the scheduling algorithm known to provide minimal service time in non-bulk arrival systems, scan, is a poor choice. He have determined why SCAM behaves poorly and have found another algorithm, SBF, which consistently outperforms it. Results which allow generalization or specialization of our findings to other conditions have been developed. Data on the performance of an actual system has been collected and analyzed. This data can provide a foundation for almost any investigation in the area of large interactive information retrieval systems. The results of this thesis need not be restricted to the domain defined in Chapter 2, that of a timeshared information retrieval system. The essential assumptions of bulk arrivals and the blocking of some processor until all the requests of a bulk are serviced are met by other systems. Examples include most inverted file or database systems, timesharing systems with pre-paging, swapping systems using shared pure procedures, and scatter- gat her read/write devices. Given these basic conditions it appears the arguments advanced and conclusions reached can be extended. Suggestions for Future Work Two interrelated extensions of the present work are consideration of channel utilization and multiple devices. Let us define the channel utilization for a given algorithm as the ratio of transfer time to request service time. As Figures 5.1 111 and 5.2 illustrate, this is a function of device type and scheduling algorithm. Channel utilization provides a measure of the efficiency of an algorithm and could be used to rate algorithms. It also provides an estimate of the amount of time a channel would be required by an active device. Using this information, arrival rates, and the core usage and bulk service time from the current work, a model of a multiple device system can be constructed and analyzed. Questions about numbers of devices per channel, channel capacities, multiply connected devices, and general system architecture can be considered- Performance prediction and system reconfiguration for new and existing systems can also be studied. The NEDLINE data referred to in this work and detailed in Appendix A provides a wealth of information about an actual system. The data deserves more direct consideration for the information it can provide on query structure, user behavior, and system behavior. A careful study and clever analysis would go a long way toward providing a clear definition of the process of information retrieval as it is actually practiced. Models can then be built based on what is rather than what might be. A series of open questions concerns what might be rigorously proven about the relative performance of the algorithms defined here. By extracting essential behavioral characteristics it may be possible not only to prove the relative merits of each of the five algorithms but also determine necessary traits of even better algorithms. Such results could direct the synthesis of 112 ni g 2 D Q O CYJ CD CVi Si: *)! oj> : 00't +■ +■ 4- OBD 09*0 Ofi'O 06*0 NOUbZIlIin 13NNUH3 § ffl V tf I oC. o CO ^ . LU «H • a — « •* 4* D 18 s g 00 tP 113 en i — i Pi U)< «: ; ! *\ o CVJ CD E u. »>: u,): *.h ^x 00*1 + + + +■ § ffl o CM N o 9 CO cn UJ oQC ma IS •H o M o •H • V IT) C a> «> *> u O 3 a. e» e fc. o •H +» * N c c It) (J o in 6 o o o 08'D 09'0 Ofi'O OS'O NOIlHZIlIin 13NNUH0 OO'tP 114 new algorithms. An attempt to discover a simple structure underlying what appears to be a horribly complex set of interactions should be considered. The prospects for success seem slight but the potential benefits are undeniable. 115 REFERENCES 1 Herner, S. and fi. J. Vellucci, Selected Federal COmputer-based I nformation Systems , Information Resources Press, Washington, D.C., 1972. 2 Organick, E. I., The M DLTICS System: An Examination of j.ts Structure, MIT Press, Cambridge, Mass., 1972. 3 Milner, J. M. , "A Multiprocess, Multiuser Executive for an Experimental Information Retrieval System", M.S. thesis, University of Illinois, Department of Computer Science, Report No. 75-736, 1975. 4 Stellhorn, tf. H. , "A Specialized Computer for Information Retrieval", Ph.D. thesis, University of Illinois, Department of Computer Science, Report Mo. 74-637, 1974. 5 Hollaar, L. A., "A List Mergeing Processor for Inverted File Information Retrieval Systems", Ph.D. thesis, University of Illinois, Department of Computer Science, Report No. 75-762, 1975. 6 Hollaar, L. A., "An Architecture for the Efficient Combining of Linearly Ordered Lists", Second Workshop on Computer Architecture for Non-Numeric Processing, Jan. 22-23, 1976. Liu, J. W. S., "Algorithms for Parsing Search Queries in Inverted File Document Retrieval Systems", University of Illinois, Department of Computer Science, Report No. 75-718, 1975. 8 Liu, J. S. tf. and J. H. Milner, "Probabilistic Models of Inverted File Information Retrieval Systems", presented at International Symposium on Computer Performance Modeling, Measurement, and Evaluation, Boston, Mass., March 29-31, 1976. 9 Morgan, J. K., "Description of an Experimental On- Line, Minicomputer-Based Information Retrieval System", M.S. thesis. University of Illinois, Department of Computer Science, Report No. 76-779, 1976. 10 Scherr, A. L. , "An Analysis of Time-shared Computer Systems", Ph.D. thesis, Massachusetts Institute of Technology, Project MAC, MAC-TR-18, 1965. 11 Denning, P. J., "Virtual Memory", Computing Surveys, Vol. 2, No. 3, 1970. 116 12 Denninq, P. J., "A Note on Paging Drum Efficiency", Computing Surveys, Vol. 4, No. 1, 1972. 13 Grossman, D. D. and H. F. Silverman, "Placement of Records on a Secondary Storage Device to Minimize access Time**, J. ACH, Vol. 20, No. 3, 1973. 14 Gotlieb, C. C. and G. H. HacEwen, "Performance of Hovable-Head Disk Storage Devices", J. ACM, Vol. 20, No. 4, 1973. 15 Turnbull, C. J. H., "A Comparative Analysis of Several Disk Scheduling Algorithms", University of Toronto, Technical Report CSRG-18, 1972. 16 Coffman, E. G. and P. J. Denning, Qperat ing System s Theory, Prentice-Hall, Englevood Cliffs, N.J. , 1973." 17 Fuller, S. H. and F. Baskett, "An Analysis of Drum Storage Units", J. ACH, Vol. 22, No. 1, 1975. 18 Skinner, C. E. , "Priority Queueing Systems with Server-walking Time", Oper. Res., Vol. 15, Ho. 2, 1967. 19 Oney, W. C. , "Queueing Analysis of the SCAN Policy for Moving-Head Disks", J. ACM, Vol. 22, No. 3, 1975. 20 Abate, J. and H. Dubner, "Optimizing the Performance of a Drum-like Storage", IEEE Trans, on Computers, Vol. 18, No. 11, 1969. 21 Lum, V. T., M. E. Senko, C. P. Vong, and H. Ling, "A Cost Oriented Algorithm for Data Set Allocation in Storage Hierarchies", Comm. ACH, Vol. 16, No. 6, 1975. 22 Stone, H. S. and S. H. Fuller, "On the Near-optimality of the Shortest-Latency-Time- First Drum Scheduling Discipline", Comm. ACH, Vol. 16, No. 6, 1973. 23 Teorey, T. J. and T. B. Pinkerton, "A Conrparitive Analysis of Disk Scheduling Policies", Comm. ACH, Vol. 15, No. 3, 1972. 24 Hilner, J. H. and J. w. S. Liu, "Secondary Storage Access Scheduling for a Multiuser Inverted File Processing System", presented at ORSA-TIMS Special Interest Conference on the Theory and Applications of Scheduling, Orlando, Fla. , February 4-6, 1976. 25 Fuller, S. H., "An Optimal Drum Sceduling Algorithm", IEEE Trans, on Computers, Vol. 21, No. 11, 1972. 26 National Library of Hedicine, MEDLINE Reference Manua l. National Technical Information Service, PB-222 991, 1973. 117 27 National Library of Medicine, "Medical Subject Headings: Alphabetic List 1975 H , National Technical Information Service, PB-234 189, 1974. 28 National Library of Medicine, "Medical Subject Headings: Tree Structures", National Technical Information Service, PB-234 190, 1974. 29 Knuth, D. B. , The Art of Computer Programing, fol, 1^, ftddison-Wesley, 1968. 30 Gordon, G. , System Simulation , Prentice-Hall, 1969. 31 Mac Dougall, H. H., "Computer System Simulation: An Introduction", Computer Surveys, Vol. 2, No. 3, 1970. 32 Kleinrock, L. , Queueing Systems Volume l£ Theory . Hiley, 1975. ~ " 33 Conway, R. W., W. L. Maxwell, L. M. Miller, Theory of Sch eduli ng. Addison- Wesley, 1967. 118 Appendix A HEDLINE STUDY To accurately model and analyze the behavior of the secondary storage sub-system of an interactive information retrieval system, ve must be able to specify how such a system is driven by its users. To this end, amoung others, it vas desirable to study the actual operating data of such a system. Several basic questions Here formulated and data vhich might answer them vas gathered. The principal questions asked were: 1) What does a query look like? -how many terms per query -what kinds of terms are used and how -what connectives are used and how -how large are query results 2) What are the characteristics of terms and connectives? -postings per term -overlap of terms as a function of connective 3) How does a user behave? -how long does he work -how fast does he work -how much does he work -how does he chain his searches together U) How does system behave -user load in number, requests, and messages -system response to searches and other reguests 119 To answer all these questions ve required a machine readable log of all messages to and from MEDLINE, the number of postings associated with each term, and the tree structured index term vocabulary (fleSH) . Through the offices of Davis HcCarn of NLfl we obtained a transaction tape which partially satisfied our first need. Data on the number of postings for each index term was unavailable, as was a machine readable HeSH. A HeSH tree structures book [28] for use by indexers and users was obtained. To answer the question of how the distribution of index terms that are actually used (dynamic index terms) differs from the static index term distribution, or Zipf curve, modifications were made to our inhouse system, EUREKA, to attempt to develop this data. Unfortunately, usage was insufficient to build up meaningful data by the time of this writing. The machine readable, and hence easily digestible, MEDLINE data available was just a single day*s traffic file, covering the period from 12:45AM to 7:40PM on Monday, January 13, 1975. Due to the widespread use of the system, including Europe, and the nature of computer users, the system was loaded over the complete time span. The tape we received contained 38,651 records, of which only the first 38,799 could be correctly transferred to a second tape by the CSO IBM 360/75. Bach record contained the information shown in Table A. 1. Postj-pn i-e~ I 9 10- 12 13 14- •18 19 20- ■26 27 28- •29 30 31- •32 120 Terminal I. D. (user signon name) blank TSO line number blank YYDDD - Julian date blank HHNMSST - Military time in hours, minutes, seconds, and tenths blank unused blank Hexidecimal zero if an input record, non-zero if an output record 33 Blank if input record, first character of message if output record 34 Hexidecimal length of message if input record, second character of message if output record 35 First character of message if input record, third character of message if output record 36-89 Up to next 54 characters of message - input records may contain C'$* which erases the whole message or X'EI 1 which rubs out the preceding non-X'H 1 character P1EDLINE Tape Format Table A. 1. Because at most the first 57 characters of each output message and 55 or less characters, depending on rubouts and line kills, of the input messages appear in the traffic file, not all messages can be classified and processed. Such messages are here referred to as truncated messages. Fortunately the input message records contain a character count which allows the detection of truncated messages, since by definition they contain more characters than fit in the buffer. However, since the buffers aren't cleared before being reused and output messages have no embedded length count, undetectable cases can occur in output message analysis. These problems are most severe on search statement input messages and search result messages when 121 displayed in 'long' mode [26]. The program which collects statistics to answer as many of the guestions posed earlier as possible simply pretends it is hedline. User input messages are scanned for editing action characters to produce clean messages. Tables are updated using the message content and time stamp included in each record. Messages which reguest LOGIN or LOG00T allocate or deallocate table space for a given user. The terminal I.D. field that appears in every message is used to associate messages with users. Output messages are analyzed to see what the real MEDLINE did; the model follows accordingly, recording statistics as it goes. Since the state of the simulated HEDLINE machine is unknown when the transaction tape begins and ends, the results may be biased by the startup and shutdown assumptions made in the model. These assumptions are that there are no users at startup and that all users are forced to logout at shutdown. In all the measurements that follow a sample size is indicated. For statistics with large sample sizes the boundary conditions and embedded pathological cases should be less significant in the final result. The acid test of the results given here would be to run tapes of several other days through the program and compare the results. This has not been done as interest in these results aside from the current author have been nil. Since neither a MeSH tape or postings count list was available directly in machine readable form for MEDLINE, alternate approachs were taken to gain some knowledge about index 122 postings sizes. For searches that referred to only one term the # number of postings in the result is trivially the same as the number of postings of the term. Distributions for single term searches for each term class were collected to approximate the dynamic distribution that could have been obtained by using the postings count of each individual term of every search. This approximation ignores the thorny guestion of whether or hov the dynamic usage of terms varies as a function of the complexity of the search. To determine the number of basic index terms which an actual exploded term called up, all exploded terms were extracted from the tape and looked up in the fleSH [28] by hand vhere the number of lover level terms vere counted. What follows are the tables and graphs of the analysis results, a discussion of the answers these results provide to the questions at the beginning of this appendix, the questions yet to be answered, and questions raised by the answers to date. A glossary of terms used in this appendix is provided, along vith a sample transaction tape listing. Figure A. 14- 123 Parameter E[x] a X min max sample figure logged in users 8.54 6.72 25 25 A.1 search request 11.24sec 24.84 600 4340 A. 2 interarrival time real search 11.83sec 27.42 250 4058 1.3 completion time search completion 1.01 1.94 25 4058 A. 4 CPD time input messages 20.21 12.71 1 59 793 per minute output messages 29.71 19.24 94 793 per minute system response 3.90sec 4.51 35 14972 A. 5 time MEDLINE System Statistics Table A. 2. Parameter E[x] a X min max sample figure session time 16.30min 25.09 200 525 searches per session 7.70 12.96 100 525 A. 6 searches per minute 0.63 0.38 3 525 per user input messages per 30.27 44.73 390 525 session output messages per 44.29 64.72 570 525 session user response time 28. 15sec 29.54 200 14476 A.7 MEDLINE User Statistics Table A. 3. Parameter E[x] a X min max sample figure terms per search 1.92 0.99 1 8 4334 A. 8 statement basic terms per 30.25 50.97 250 650 A. 9 exploded term single normal term 573.79 1164.26 5000 958 A. 10 postings exploded term 2221.90 1923.97 5000 258 A. 11 postings search statement 273.55 924.33 5000 63 A. 12 term postings search result 687.75 1398.28 5000 4141 A. 13 MEDLINE Query Statistics Table A. 4. 124 Number of Terms in Search Term type 1 2 3 4 5 6 7 8 Total normal 1194 1866 924 486 66 110 7 32 4685 explode 293 227 101 51 1 4 3 680 ss number 77 1941 295 363 108 132 18 32 2966 Total 1564 4034 1320 900 175 246 28 64 8331 Term Osage in Queries Table A. 5. Number of Terms in Search Term type 1 2 3 4 5 6 7 8 Total normal explode ss number 76.3 18.7 4.9 46.3 5.6 48.1 70.0 7.7 22.3 54.0 5.7 40.3 37.7 0.6 61.7 44.7 1.6 53.7 25.0 10.7 64.3 50.0 0.0 50.0 56.2 8.2 35.6 Percent Osage of Terms in Queries Table A. 6. Number of Terms in Search Connective 1 2 3 4 5 6 7 8 Total AND 1367 221 225 39 98 9 25 1984 OP 448 576 405 97 96 15 28 1665 AND NOT 184 40 37 1 11 4 277 Total 1999 837 667 137 205 24 57 3926 Connective Usage in Queries Table A. 7. Connective 1 2 Number of 3 4 Terms 5 in Search 6 7 8 Total AND OR AND NOT 0.0 0.0 0.0 68.4 22.4 9.2 26.4 68.8 4.8 33.7 60.7 5.5 28.5 7 0.8 0.7 47.8 46.8 5.4 37.5 62.5 0.0 43.9 49.1 7.0 50.5 42.4 7.1 Percent Osage of Connectives in Queries Table A. 8. 125 Total Number of Terms in Query t Terms 1 2 3 4 5 6 7 8 Total 370 667 59 49 13 5 2 1 1166 1271 1823 365 197 34 39 3 8 3740 1487 603 290 85 6 3 1 2475 1194 834 60 8 4 1 2101 1 293 161 54 15 1 524 77 887 55 6 1 1026 516 99 90 5 3 713 2 33 16 8 2 59 527 45 87 6 665 222 14 6 29 1 272 3 5 1 6 50 5 5 30 1 91 64 1 1 1 6 73 4 5 5 42 5 3 2 6 58 6 6 5 12 12 2 2 6 5 5 7 1 1 1 1 8 1 1 1564 2017 440 225 35 41 4 8 normal Total 1564 2017 440 225 35 41 4 8 Explode 1564 2017 440 225 35 41 4 8 SS Number Note: 347 searches were truncated out of 4334 Term Type Usage Distribution Table A. 9. 126 t Conns 1 Total Number of 2 3 4 Terms 5 in 6 1564 1563 1564 650 1550 1833 297 110 403 107 11 203 16 2 34 5 32 1 1 1367 448 184 65 38 34 15 107 9 4 1 1 2 7 2 19 78 269 3 99 11 11 12 12 10 33 2 3 23 4 92 2 1 4 26 1 4 4 2 15 5 1 5 6 7 Total 1564 1564 1564 2017 2017 2017 440 440 440 225 225 225 35 35 35 41 41 41 8 Total 1 4 1 5 2641 3236 4078 2 1451 597 237 1 1 199 345 17 3 3 3 5 37 128 2 4 1 6 20 6 1 1 1 1 4 4 4 8 8 8 AMD OB AID NOT Note: 347 searches were truncated out of 4 334. Below diagonal elements are due to truncated searches, since in complete searches the number of connectives is one less than the number of terms. Connective Type Usage Distribution Table A. 10. * * * # ♦ * • • # rn # c\ * # # tN * IN * ♦ ♦ »" * IN « * * CJ • »> • * # * IT *# *- * * * # * * u. * * »" * *■ * * * # r* * * *- ■w * * ♦ * * * * * ♦ * «• * * *■ ♦ * * # * ■» * * * # u. * * * ♦ * # # * * * # ♦ ♦ * * * # ♦ * * * * * *- # * * # ♦ *■«•** * * * * # « * * *»■•*♦♦ * * * * * ♦ * # * * * # # * # * * * * * # # # # ♦ * IT 1 * * * # ♦ # * * # # * * r- ♦ # # # # # * # * * # * # # * # # * * » * * # # * * # # # * # # * * * * 3 * # * * * * # # # * ♦ # # ** «- # # # * * * ♦ # ♦ * # # » * * * * * * # # » » * » # * * * # # # * # * # * * * # * # * ♦ * * * * * * # * » # * * # # ■» # * ♦ # # # -' 3* CO r-i in cu O I T3 (D 0) • en •« * o H • a u M 9 Q_ BE □ 5 UJ W X UJ DO 000 '0 132 CO QZ LU a a QOD'fl rnrsHGOHd 133 r cc UJ h- Q UJ Q _J Q_ X UJ DC UJ Q_ CO x: DC UJ j— CJ CO CT CD CO 4 c\J a in a? a Km z: DC UJ o u e u « n V o H • ah M • M 4 U 0> 4) U Cu 9 id cn cc CD CD u 4) H O •H V) « CO h- Olh'D 1 1 y. 8Se."0 9hd"£) h9l'l xinr0H8oud C\J cn a id SBD'O OOO'O 134 060 '0 £L0'0 fiSO'O MQ'O jL.i.nrgdsodd nyrAryye BIO'O GOO^O 135 LU h- LU CO -z. o 0_ CO LU DC LU I— CO >- CO sie - o 2i.ro B2T0 980 jLinrsuBQdd EhO'D 000 '0 136 UJ z: UJ CO Q_ CO UJ DC DC UJ CO S80"0 890 '0 ISO'O hEQ LIO'O OOO'O 137 OhZ'O fiM'D 9&0'0 JLinrBUBOUd BhO'O 000*0° 138 LxJ on ID Q_ CJ (H CE UJ CD SCO 09'0 Sh'O 0E.0 nnrausoud sro EH I CM out I 00 0° 139 I — I en CO LU CO cc LU Cu CO n CJ cc ex LU CO -- =r -- o CO CO C\J CM Ln rvi CD CVI °2 CO CD UJ cn UJ X CC UJ ootn e o •H 3 . • U (■ • t» a* « CVJ r-' CD cn OOE'O ohe'o oeru osi jLirir9H9oyd 090 000 '0 p < •• or WOL h UJUJ z to co uj 0,0 UJ CO •> »-« CVCO Q O I-- *** z or < UJ o ,_J *-» I u O UJ to or z 3 <. o x uz * o Q Z Z j< CM O ' -* or & CL UJ CO 3 o o CM CO CO in o CO UJ CO 3 c*~ O I m co CO *i CO r- CO » o UJ X O- CC UJ CO 3 o o •—i «-• -J < co or •» 3 UJ co I < UJ CO 3 *-• «* o !> < CO z i— i O zor < o >u < a: I < CO o < O UJ O CO I 00 CO 4" CM o c- CO Q. f\J 4" — or. — la CO CO CO CM CO L ••' o •• o o o, «-* o or of a a. o *■** z r»< H — 4- o or »- o CO a. co »— i — ■ H UJ ^0 »-< Z •-• at: UJ — "D or UJ UJ CO z K c/> x o < z or o r-~ O 4" 0< a. lm o m •-« 3 CO ^ CO 1 -j UJ _J Z|3 O u, z * r- Z ►— t ••I or o a. oit or 0. Z CO Z UJ - or UJ or 3 UJ > CO CO < X co t or CO UJ UJ CO «/> 3 < UJ CO a. CD CO CO 3 X O *-• co i I < UJ CO or co UJ z UJ > ! in I CO t tr —j a o> en • m o> t m M • 3 co ; «-4 1 o z o r-« CO a »-• o S-i x o I >- .. CO o a c, X or. -r, o_| to co co i o o or O co or o re or a. ! ° l o _) 1 UJ -4 or ■Nj UJ M z 3 UJ CO > <. or uj uj I cc O _J UJ 1-4 u. x z o. uj r»- X o > o Q Z iii i r- O 4- CO f*- >- «n K- 4- »-< »•* > 4* *-* eg »- o H- < _J UJ -J X O o •-H UJ O X o -J I o •"I CO o CO -J < z »-4 CO o UJ Of CO < < X o X o a or co< UJ z o O CO I CM I • UJ Q z or «-» o a u UJ **J -j < < •-» z o a Kl CO z uj uj CO X • H 4- *Z ■-. o I o x or 3 U 4- 4* CO ' co co «/>l co or •-• 3 4- -> CNJZ ■ to or ♦• sle- et a o ■» o I- Z H co < CO Q. IQ. cO m z n — 3 — O •~t CO CM CO » CO CO i CO CO a o z z cc o oocooooooo oorQoo'Oeoo >0 <0 \b r** co o 4" 4" 4" 4" 4" u*\ cu evi c\j c\j rvj cnj im c\j cm c\r c\j ro co rO' co co ro ro CO ft o r*" 00 fH CT 1 t— » f— t CM CM 4- in 4- u*i CsJ CM rsj CM (M oo!ooeoo COOh in i^ m cm cm rj CM CM CM CO CO CO COl CO CO CO ■HO^CMniM^OlA'^-t^OO Mfomm k ->Or-p*K l cocosff'(?> mmmirmu-iiniAmlmmmmm CMCMCMCMCMCMCMCMCMCMCMCMCMCM CMCMCMCMCMCMCMCMCMCMCMCMCMCM cocncncocorOcocococococococo o o t>4- o o o o o o o o o o 4- m <© vO t-l f-I rH ^-« o o o o ro co CO ro CM CM CM CM CO CO CO CO Hrt|Hr-4H l ^HH!i-t-^Hr«H->'H>-o «o CM UJ UJ UJ o o o o o in' in r-jr- cm in UJ UJ o o o DUI/1 «I in in r» ■ r- r- r~ in en co cc uj o O u. o o o o ■-• m co ro o o o o I-, O O 3 co I X o o O i| <_> O CS X X X o i_> «— » c* i J( o o o z z d o oi o O, Q' UJ UJ UJ UJ UJ X W \W X X 4 t •t-4 Si {J e Sf^S. 141 A central result of the MEDLINE study is some detailed information on the nature of usee queries. Since the purpose of this thesis is' to analyze a portion of a system designed to process queries, an understanding of the nature of queries will define the work the system must handle. Individual queries tend to be small in size, averaging 1.92 terms. Each term corresponds to one postings list, with the exception of exploded terms. Each exploded term in a query produces an average of 30.25 basic (non-exploded) terms. Since exploded terms make up only 8.2% of all terms observed, the effective average number of basic terms per query is 6.50; meaning each query produces 6.50 postings lists on average. The standard deviation of the number of postings resulting from a single query is 6. 40, so assuming a normal distribution, 95% of all queries should reguire less than 20 postings. Using the geometric distribution assumed in Chapter 2, 95% of all queries would require 18 or less. Note that if the measured mean of 6.50 is used to compute the standard deviation of the geometric distribution, the result, 5.98, is in good agreement with the measured value of 6.40. One might wonder if the apparent small size of queries is truly a user characteristic or merely a manifestation of a bias in system behavior in favor of small queries. Two facts and a notion seem to refute this possibility. First, the small number of terms per query is consistent with results of EUREKA user studies. Second, 35.6% of all terms used in queries in the MEDLINE data were of the search statement number variety. Terms of this type recall the result of an earlier search (by its number) for use in the present 1«»2 search. This observation meshes with the notion that people solve problems by making and reaching subgoals on the way to the final goal. While the length or depth of the average chain or tree of queries was not measured directly from the data, simple estimation approximations based on only chaining result in an estimate of 3.09 gueries per intellectual search. HEDLINE users are encouraged to perform only one such intellectual search per session. The measured average number of gueries per session is 7.70, which does not conflict with the chain approximation and leaves room for false starts in the intellectual search. Data in Tables A. 5, A. 6, and A. 9 show how the types of terms vary as a function of the length of gueries. Single term gueries perform no explicit logic; they only report the number of documents linked to the term. The relatively high usage of normal and exploded terms in single term gueries reflects this probing behavior. Use of search statement number terirs is low as this only serves to refresh the user's memory on the results of an earlier query. Use of exploded terms drops off rapidly as the number of terras in the guery grows (data for 7 and 8 term gueries is suspect due to small sample size and truncation effects). Queries of two or more terms appear to mix new terms and old results in roughly equal measure. This process, depending on the connectives used, would add or remove documents from the evolving result. Tables A. 7, A. 8, and A. 10 depict the types of connectives used as a function of the number of guery terras. The intersecting connective (AND) dominates the two term gueries; 143 which correspond to reducing the size of the evolving result. Queries of three or more terms are dominated by the union connective (OR) , which increases the size of the evolving result. That the average query size is 1.92 seems to imply that users generally probe single postings and combine two postings in a reducing manner. This behavior corresponds to the winnowing out function that information retrieval systems are intended to perform. The relative complement connective (AND MOT) , also a reducing connective, sees relatively little use. what use it does see is principally in two term queries. The nature of the postings lists produced and consumed by the MEDLINE system provide some guidance in assumptions on disk and merger operations. The shape of the distribution for result postings lists appears exponential with a very long tail. Distributions for the postings sizes of the three term types are not directly available, since data on the postings size of each term in the MeSH was unavailable. However, these distributions were approximated by tabulating data on all single term searches; in these searches what comes out as a result, which is available, is just what went in. Note that the distribution of the postings terms actually used in queries need not be the same as the static distribution of all terms in the MeSH. In fact, there is evidence that terms of extreme high and low postings counts in the MeSH are infrequently used. Attempts to accurately study this effect were thwarted by lack of necessary data. Lack of data also made it impossible to measure the overlap factor of postings lists actually used for each of the three connectives. Prom the definitions of the operations, the factors can be bounded as follows, where |x| means the length of list x: c = a and b < |c| < rain ( I a| , | b| ) c = a or b max (|a| ,Jb| ) < |c | < |a| ♦ | b| c - a and not b max (0, j aj- | b|) < |c| < |a| These bounds demonstrate that and and and not generally reduce the size of the result relative to their inputs, while or generally increases it. A detailed study of actual gueries where input and result postings sizes are known could provide functional forms and coefficients to approximate |c| for all three connectives. This would be of value in estimating storage requirements and merge patterns for coordination of lists. Observe that the results of an and or and no t can be built in the space required by one of its arguments, while no such scheme appears possible for or.. User data shows a pattern of short sessions (16.30 minutes average) in which a fair amount of work (7.7 searches average) is done. This reflects the MEDLINE policy of performing one preconceived intellectual search at each terminal session. The user comes to the system with a veil thoughtout guestion and perhaps some offline preparation using the MeSH books [27,28]. The user directs an average of 30.27 messages to the system, while the system produces an average of 44.29 messages for the user. The user response time is 28.15 seconds, with a standard deviation of 29.54. It is of some interest that this user "think and type" time is not significantly different than that which Scherr found for CTSS [10]. The basic characteristics of the 1U5 interactive use seem to carry over to the information retrieval system. The user generates a search request about every two minutes. Of all input messages, 25. H% are search requests. The data collected does not measure the serial correlation between search requests as a part of the input stream. With such measurements and a more detailed breakdown of the frequencies of various commands, all obtainable with some difficulty from the available data, a Markov chain model of the user behavior could be constructed. In combination with the guery structure information, a number of such user models could generate standard loads for benchmark and performance measurement purposes. Since the present work was not directed in this area the necessary work was not undertaken, however it appears to be an area of interest and potential worthy of further research. The system behavior is not as transportable as user behavior but these statistics do give some idea of the level of service which can be provided by an interactive information retrieval system running on conventional hardware. MEDLINE service is provided under the TSO option of VS2 on an IBM 370/158 at the National Library of Medicine at Bethesda, Maryland. The hardware for MEDLINE is collectively known as EhtiILL III to distinguish it from the hardware that runs MEDLARS, the batch system from which MEDLINE grew. The MEDLARS hardware is referred to as OPFHILL. The two systems share files and offline searches for OPFHILL can be prepared and edited via ELHILL. The nature of any batch or other TSO work done on ELHILL III in competition with MEDLINE is unknown to this author. 146 The average number of HBDLINB users daring the period data was collected vas 8.54. Because data was only available for a single day this and other system statistics may be more pathologic than previous statistics. System response time to all messages was 3.90 seconds average, while queries required 11.83 seconds on average. This implies average response to non-search input messages vas 1.2 5 seconds average. To prevent overly long searches monopolizing the machine and to allow users to abort obviously faulty searches, the system queries the user after his search has consumed a quantum of processor time. The user may elect to continue or abandon the search at the end of each quantum. Data indicates that searches take almost exactly one quantum on average (1.01) with a standard deviation of 1.94. That the searches take an average of one quantum is more likely a result of tuning the quantum size than a manifestation of some universal law. If we accept hear-say information that HBOLIHE spends 9 5% of its time merging, we can conclude that a quantum is roughly 1.4a seconds, where a is the percentage of ELHILL Ill's time devoted to MEDLINE. Thus an average search, which consists of 6.5 postings lists of 601 entries each take roughly 0.5 to 1.5 seconds of 370/158 time to process into a result list of 687 entries. The large deviation of quantum time indicates that users do pursue searches of up to 4 quantums regularly and that 10 or more guantum per search occur about 1% of the time. Additional thought about and study of the data collected here and available in the transaction log appear certain to produce a better understanding of what people do when they use an 147 information retrieval system and hov veil one system does information retrieval. Benchmarks and user modeling data are available. Clues to what is and is not important in an information retrieval machine are available. A great deal remains to be discovered and explained about vhat we do vhen we search for answers in text. Glossary of Terms logged in users: number of usees actively connected to the HEDLINE subsystem of T50. search request: search statement: query: a syntactially correct combination of terms and connectives which express the desired contents of documents to be retrieved from the data-base. search request interarrival time: time between the arrival of successive queries to MEDLINE. real search completion time: the real (wall clock) time between the submission of a query and the result response* search completion CPU time: the number of time quantums required to complete processing a query. input messaqes per minute: the number of messages from users to the system arriving at the systerr per minute. output messages per minute: the number of messages leaving the system per minute for all users. system response time: time from the arrival at the system of a message from a user to the departure from the system to the user of a reply message. session time: time from "login" command by user to "good-bye" message from system. searches per session: number of search statements submitted by a user in one session. 146 input messages per session: number of messages from user to HBDLINE in one session. output messages per session: number of messages from HBDLINE to a user in one session. user response time: time from departure of message from HBDLINE to arrival of reply message from user. HeSH: Medical Subject Headings, the set of predetermined words and phrases under which all articles in HBDLIHE are indexed. Each such word or phrase is called an index term. The index terms are ordered in a tree structure based on specificity. Bach index term has both a text and a tree number descriptor which locates it in the hierarchy- index term: see HeSH normal term: one of the index terms in HeSH or its equivalent tree number descriptor. exploded term: a tree number descriptor preceded by the function EXPLODE or EXP. Such a term produces the or of all its basic terms as a result. search statement term: a term consisting of the search statement number of an earlier search. The term represents the results of the earlier search. basic term: with reference to the explode of a tree number descriptor, that term plus all terms below it in the tree structure. posting: pointer to a document in the data base. The postings of a term are all such pointers for the term, they collectively enumerate the documents indexed by the term. terms per search statement: the total number of normal, exploded, and search statement terms in a query- terms per exploded term: the number of terms below the exploded term in the tree structure. ss number: search statement number term. connective: the logical operators used to express relations between terms. Specifically AND, OB, and AND NOT. truncated search: a search statement whose length in characters exceeds the size of the message buffer. Truncated searches are not complete recordings of the actual search statement because only the first 57 or less characters are stored in the traffic file. 1U9 Appendix 8 DISK/DROH SIMULATOR Three approachs are possible to the study of scheduling policies in an interactive information retrieval system: measurement on an actual implementation, simulation of an implementation, and analytic analysis of an implementation- Direct study with an actual or prototype system was simply not feasible in terms of time, money, or manpower. Simulation and analytic studies are possible, each with its own limitations. It quickly became apparent that gueueing theory was not powerful enough to handle the complexity of the problem, especially in the area of scheduling disciplines. Results obtainable would be a function of how cleverly the problem could be reshaped to fit into known gueueing theory problems. Generally such toying with the problem would reguire simplifying assumptions. Clearly such toying has the potential to radically alter the problem. An independent check on the results of such changes was essential therefore. Thus simulations are seen filling two needs as an adjunct to gueueing theory; handling problems beyond the scope of theory and providing an independent check of approximations made in the name of theoretic tractability. A third function of egual or greater importance was to provide a quick check of the assumption that scheduling did in fact matter. With these objectives in mind the design of the simulator was begun. 150 Simulations can be divided into tvo classes, discrete and continuous. Continuous systems are generally associated with sets of equations vhich define how conditions vary in time. Discrete systems, of which our drum/disk model is a member, are characterized by a pattern of events vhich occur in time. The classic discrete event simulator example is Knuth's elevator simulator [29], in which events are the arrival of a customer, arrival or departure of the elevator to or from a floor, etc. In our problem the three principal events are the arrival of a bulk of service requests, the arrival of the moving arm (in disk cases only) at a cylinder, and the completion of a record transfer. The times at vhich these events occur relative to each other are determined by probability distributions and the system's current and desired states via time-motion equations. The current state is the location of the arm in terms of cylinder number and rotational position, plus some possible scheduling algorithm related information such as direction of arm motion. The desired state, again in terms of access mechanism location, is a function of the current state, the scheduling algorithm, and the queue of unfilled service requests. The simulation can be driven in one of two manners; either time causes events or events cause time. The former, more natural approach behaves as follows: time is advanced one unit, the state of the system is updated, and any events scheduled to occur do occur. The alternate, and in our case more efficient method, is to maintain a time— ordered queue of future events. In this system time advances to the next event, the state of the 151 system changes, and the event causing the advance occurs. New future events are spawned by each event as it becomes current, based on the then current state of the system. The question of what language to code the simulator in was based on the nature and complexity of the general outline just given. At least three simulation languages, GASP, GPSS, and Simscript, are available on the CSO 360/75. However, none of these are supported on the 370s in Chicago accessible from Urbana. With the heavy workload of the local machine, weak support by consulting staff, and no second source, they were dropped as choices. The three choices would then appear to be BAL, FORTRAN, and PL/I. For speed in coding and possible transportability to a non-IBM machine, BAL was dropped. Between PL/I and FORTRAN there were the following considerations: speed of compilation and execution, optimization options, expressive power, and transportability. FORTRAN was chosen for the following reasons: compilation, execution, and optimization were as good or better than PL/I, recursion and block structure were not essential to the simulator coding, and only FORTRAN was also available on the local DEC-10 and PDP-11. Interactive checkout on the DEC-10 and possible batch production on our own PDP-11 were viewed as possible ways to save time and money. Interactive debugging proved impossible due to the size of test cases. Batch production on the PDP-11 was attempted but the 360 was observed to be 12 to 20 times faster. The poor input/output facilities of the PDP-11 would have required transporting results to the 360 lor printing, plotting, and storage. Also three hundred to six 152 hundred hours of PDP-11 time vere simply not available to complete the required computations. General Oyer, y.jew of Si mulator The simulator system which was developed consisted of the simulator itself, several programs to maintain a dataset of results stored on a private disk, and printing and plotting routines to assimilate results from the dataset for presentation in printed or graphical form. The basic system is depicted in Figure B. 1. Parameters of the simulation cases to be done are submitted in card image. Results are filed on the dataset, classified by those parameters. Management programs can initialize the dataset or list its index. A graphing program, driven by data cards, can collect data points from the dataset based on specific parameter values and produce nicely scaled and labeled plots. The simulator is written in a top-down manner which mirrors the logical structure at some cost in efficiency. Multiple labeled COMMON areas are used to collect in logically related groups the global variables of the simulation. Some of the arrays logically belong to the same data structure and are indexed by a common variable. Had the simulator been written in PL/I these arrays would have been an array structure but due to type restrictions in POBTRAH multiple arrays were required. Extensive error and self-consistence checking is provided, again at some cost in speed. Svitchs in the input parameters control 153 internal debugging aids which provide formatted listings of major simulator tables. These svitchs are forced on in the event of an error to provide maximum diagonistic assistance. The main flaw of the simulator is its inability to discriminate between very large but stable queues and truly unstable (growing without bound) queues. For simulations in which the system is near the edge of saturation the stocastic nature of the simulator results in some cases which overflow the queue capacity of the simulator while others don't. Queue capacity could have been increased but the additional cost in core charges and the additional CPU time required to overflow the longer queues in truly unstable conditions was prohibitive. The basic outline of the operation of the simulator is as follows: 1) read in a count of the number of sets of parameters to be processed, repeat steps 2 to 8 that many times. 2) read in a set of parameters and do per parameter set initialization, then repeat steps 3 to 5 as many times as called for in parameters. 3) do per case initialization. i») simulate until the limit of simulated time or bulk arrivals is reached or until a queue overflows. 5) if simulation ended normally, collect statistics for this case. 6) combine results of all normally terminated simulations to produce results with confidence intervals. 7) write the results into the dataset if file switch is on. 15a 8) print results summary for hand checking of results for this set of parameters. In all the simulation consists of a main program and 22 subprograms. There are 8 labeled common blocks. The source is approximately 1375 cards and the resulting object module reguires 10 2K. The simulator can perform approximately 9U0 simulated drum accesses or 705 simulated disk accesses per minute of IBfl 360/75 time. Drum access can be more guickly simulated because of the absense of arm motion simulation. 1^0 Guide The format of the data deck is one card containing the number of sets of parameters to follow followed by that number of sets of three data cards. 155 Card Col. Contents (FORMAT) First card 1-5 Data card 1 1-10 11-20 21-30 31-40 Data card 2 1-10 11-20 21-30 31-40 Data card 3 1-10 11-20 21-25 26-30 31-35 number of cases to follow (F10.5) (F10.5) (F10.5) (F10-5) algorithm code (110) number of cylinders (110) incremental seek time (F10.5) seek start/stop time (F10. 5) simulated time limit (F10.5) bulk arrival count limit (110) dump switch, 1 to dump tables (15) trace switch, 1 to trace (15) histogram switch, 1 to print histograms (15) 36-40 file switch, 1 to save results on the dataset (15) Data Card Formats Table B. 1. Data Structures The data strucures which control the operation of the simulator are explained in tabular form below. This information, in conjunction with a listing of the simulator, should provide sufficient data to allow a skilled programmer to modify the simulator- 156 COMMON EVENTS Array (*,2) EQ(*,3) Osage link to next event (0=end) event code number event pointer (obsolete) Event codes: 1 bulk arrival 2 seek complete 3 transfer complete DISK CLINKS (*,1) (♦.2) <*,3) (♦.4) <*,5) forvard cylinder ordered list link backward cylinder ordered list link forvard rotational ordered list link backward rotational ordered list link FIPO forvard link BULKS BC0RE(*,1) <*,2) BC00NT(*,1) <*,2) total size of bulk in core currently total size of bulk on disk currently number of requests in bulk number of requests currently on disk STATST SR8(*,1) (*,2) (*r3) (*,<*) SR4(*,1) (♦.2) (*,3) (*,<*) SI2(*,1) <*,2) HISTO(*,n) sum of values of a variable sum of squares of values of a variable time of last value change sum of time weighted values histogram lover bound histogram increment unused maximum value of sampled variable maximum histogram index count of sample values count of sample values in range from SRU (*,1) to SR4(*,1)*(SI2(*,1)-1)*SR<*(*,2) n*1 is under range, n*SI2(*,1) is over range Primary index values: 1 seek time 2 seek distance 3 rotational latency H transfer time 5 busy period 6 idle period 7 bulk service rate 8 disk request service rate 9 core usage COMMON Data Structures Table B.2- 157 COMMON Array Usage SUMARY ANSW(*,*,1,*) expected value (*,*,2,*) standard deviation (*#*#3 # *) maximum value ANS»2(*,1,») traffic intensity (*#2,*) expected value of bulk service queue length (*/3,*) expected value of request service queue length ANS»I(*,*) sample size PARM (*, 1) - average bulk arrival rate (*#2) - average merge secvice rate (*,3) g - average bulk size (* r U) - average record size (*,5) incremental cylinder motion time (*,6) cylinder start/stop time {*,!) unused PARMI(*,1) algorithm code (* ,2) number of cylinders on disk (*,3) unused First index: case nuir-ber Second index: as in STATST Third index: 1 - value 2 - confidence interval COMMON Data Structures Table B. 2 (cont.) . Modules MAIN: This module implements the basic structure elaborated earlier by calls to subroutines and two DO loops. The code is short enough to be self-explanatory. INPUT: This module reads in the number of parameters sets to be expected. The variable CASES controls the outer loop of the MAIN program. An EOF condition during the READ in this module terminates the simulation with an approprate message. INIT1: This module initializes the variables in the SUMABY COMMON, which are used to accumulate the results of each trial of the simulation under these parameters and index them on the dataset. INIT2: This module initializes the structure which contains the driving information for the simulation. The last 158 function of INIT1 is to schedule a bulk arrival at simulated time zero; this first event will kick off the simulation, SIMLAT: This module is the heart of the simulator. It extracts the first element in the chronologically ordered queue of events, sets the time to the time of that event, and calls one of three routines to accomplish the current event. This action is repeated in a loop until the desired number of simulated bulks have arrived, a limit in simulated time is exceeded, or one of the queues overflows. This last condition is signalled back to this level by setting the LOGICAL variable ABORT to .TRUE. . simlat returns only after it exits its loop for one of these three reasons. BESLT1: This routine processes all the data collected during repeated simulations under the same conditions to produce confidence intervals at the 95* level for most measured results. RESLT2: FILEIT: DONE: DCNE2: DOHPS This routine adds the results of one simulation to previous results of other simulations made under the same conditions. By accumulating the value of each measurement and its square, along vith a count of the number of simulations, RESLT2 provides RESLT1 the data it needs to make its computations. This routine manipulates two datase directory and accumulated results f performed. Directory entries consis parameters of the simulation. A nev to the directory when no current en old entry vhich matches a nev resul the nev result. All entries have a they were made. Each directory entr in the second dataset which contain and histograms gathered in the asso ts vhich contain a rom all simulations t of all the entry is added try matchs. An t is replaced by time and date when y points to a region s all the statistics ciated simulations. This module calls D0NE2 and then terminates the run. It is called when an error makes continuation impossible. This module prints a summary of the results of a group of simulations. Results vhich may be questionable due to table overflow in the simulator are flagged. This module prints out in easy to read format the contents of the used regions of EVENTS, DISK, and BOLKS common areas. These three areas contain all the information necessary to understand the state- of the simulator at the time DOHPS was called. This module is generally called by any abnormal termination of the simulation. 159 BOLKIN: SEEKDN: READDN: NXTREQ: QEVENT: SETSTS ISTATS STATS: QSTATS This module bulk of nev random numbe of the bulk is added to inverse CMP generator, a random chara COMHON areas the balk's a a service re performs the bookkeepin requests arrives at the r to select a point on arrival distribution, t the events gueue using and CDP functions and a random number of servi cteristics are added to . If the DISK gueue was rrival, NXTBBQ is calle quest to be selected an g necessary when a system. Using a an inverse CDF he next bulk arrival QEVENT. Osing random number ce requests with the DISK and BULKIM empty previous to d directly to cause d scheduled. This module collects seek activity statistics and then calls NXTBEQ to select and schedule a service request. This module collects statistics on record transfers, removes the nov completed service request from the DISK data structure, and accumulates bulk statistics. If the service request just finished was the last of its bulk it also removes the bulk from the BOLKS data structure. It then calls NXTBEQ to select and schedule the next service request. This module contains the logic to select from the available requests in DISK the next request to be serviced by any one of five policies. The policy used is selected by an input parameter. Eased on the request selected, NXTBBQ schedules either a seek or read, as needed, using QEVENT. This routine places an event in the chronologically ordered list of future events. Each event is characterized by the time at which it is to occur and an event code which represents what is to occur. Each event code has an associated event routine to process the event when SIHLAT selects it as the current event. The three event routines are BULKIN, SEEKDN, and BEADDN. This routine initializes a statistics area for a given statistic. It initializes variables and determines bounds for histogram arrays. This routine is an INTEGEB entry to the STATS routine. This routine adds a sample point to a statistics area. It accumulates the powers necessary to later compute mean and variance, it keeps running minimum and maximum values of the statistic, and it adds an entry to the histogram for the value of the statistic. This routine collects additional information on statistics which are queues, to enable later computations of mean queue lengths. 160 CORSST: This routine accumulates statistics on simulated buffer storage usage in a manner similar to STATS. RAND: This routine generates a uniformly distributed continuous random number between the bounds it vas called with. IRAND: This routine generates a uniformly distributed discrete random varable with an integer value between the bounds it was called with. RAN3Z: This routine is a CSO supplied random number generator which provides uniform pseudo-random numbers between zero and one. It replaced two other random number generators which proved to have severe problems in the current context. The IBH SSP package generator vas observed to produce strongly correlated results over a lag of three. Since three calls were made to the generator for each service reguest generated by bulkin, this produced a severe anomaly in FIPO simulation results which resulted in its detection. Simulation results for FIFO using BAM3Z are in close agreement with analytical predictions and on that basic and its overall well known behavior it vas selected. Ot her P rogram s INIT: This program creates the datasets required to accumulate results from the simulator. The directory, with room for 2500 simulation result sets, is zeroed. LIST: A listing of the directory for the simulation dataset is produced by this program. The disk index, time and date of creation, and the parameters for each simulation result set are listed. PLOT: In response to control cards this program collects, sorts, scales, graphs, and labels data from the dataset. The data to be plotted, the axis labels, graph labels, and axis lengths and scales can be specified or program defaults will be used. COHPND: This program lists the complete contents of the simulator results dataset with a sorted table of contents. Each simulation set contains not only all the parameters and statistics but also histogram counts for most statistics. The resulting listing is 2430 pages at present. The results form the reference when checking becomes necessary in analytic work. 161 Source for all the programs described above, along vith sample JCL and data are available from the author. Any and all errors in the programs or this description are the responsibility of the author* 162 APPENDIX C ALGORITHM COMPARISON TABLES This appendix contains comparison tables for the five scheduling algorithms considered in this thesis. Along with Tables 3.3a-3.5b they provide uniformly weighted comparisons for reguest service time, bulk service time, and core usage summed over all reasonable combinations of {, g and i. They can be used to study the net effect of any of the three parameters, singlely or in pairs, on the three measures. Cetails of their construction and use are found in the concluding section of Chapter 3. 163 Drum Request Service Bulk Service Core Osage 6=0.25 PIPO 24 FIFO 24 FIFO 21 24 g= 2 MSCAN 21 24 MSCAN 22 2K MSCAN 34 24 i= * SCAN 40 24 SCAN 38 24 SCAN 15 24 SBP 27 24 SBF 24 24 SBF 34 24 PSBF 26 24 PSBP 36 24 PSBF 16 24 Drum Request Service Bulk Service Core Osage 6=0.25 FIFO 24 FIFO 24 FIFO 3 24 g= 5 MSCAN 25 24 MSCAN 29 24 MSCAN 34 24 i= * SCAN 45 24 SCAN 30 24 SCAN 17 24 SBF 25 24 SBF 30 24 SBF 34 24 PSBF 25 24 PSBF 31 24 PSBF 32 24 Drum Request Service Bulk Service Core Osage 6=0.25 FIFO 24 FIFO 24 FIFO 1 24 g=10 MSCAN 25 24 MSCAN 28 24 MSCAN 34 24 i= * SCAN 45 24 SCAN 28 24 SCAN 18 24 SBF 25 24 SBF 29 24 SBF 34 24 PSBF 25 24 PSBF 35 24 PSBF 33 24 Drum Request Service Bulk Service Core Osage 6=0.25 FIFO 24 FIFO 24 FIFO 24 g=20 MSCAN 26 24 MSCAN 28 24 MSCAN 32 24 i= * SCAN 42 24 SCAN 26 24 SCAN 25 24 SBF 26 24 SBF 28 24 SBF 32 24 PSBF 26 24 PSBF 38 24 PSBF 31 24 Drum Request Ser vice Bulk Service Core Osage 6=0.25 FIFO 24 FIFO 24 FIFO 24 g=50 MSCAN 25 24 MSCAN 29 24 MSCAN 34 24 i= * SCAN 45 24 SCAN 18 24 SCAN 19 24 SBF 25 24 SBF 31 24 SBF 34 24 PSBF 25 24 PSBF 42 24 PSBF 33 24 Drum Performance Comparisons Summing over i Table C. 1a. 164 Drum Request Service Bulk Service Core Usage 6=0-50 FIPO 24 FIFO 24 FIFO 29 24 g= 2 MSCAN 26 24 MSCAN 22 24 MSCAN 33 24 i= * SCAN 41 24 SCAN 33 24 SCAN 9 24 SBP 26 24 SBF 28 24 SBF 33 24 PSBF 27 24 PSBF 37 24 PSBF 16 24 Drum Request Service Bulk Service Core Osage 6=0.50 FIFO 24 FIFO 24 FIFO 11 24 g= 5 MSCAN 25 24 MSCAN 27 24 MSCAN 36 24 i= * SCAN 45 24 SCAN 26 24 SCAN 10 24 SBF 25 24 SBF 27 24 SBF 36 24 PSBF 25 24 PSBF 40 24 PSBF 27 24 Drum Request Service Bulk Service Core Usage 6=0.50 FIFO 24 FIFO 24 FIFO 7 24 g=10 MSCAN 25 24 MSCAN 26 24 MSCAN 37 24 i= * SCAN 45 24 SCAN 22 24 SCAN 10 24 SBF 25 24 SBF 29 24 SBF 37 24 PSBF 25 24 PSBF 43 24 PSBF 29 24 Drum Request Service Bulk Service Core Usage 6=0.50 FIFO 24 FIFO 24 FIFO 4 24 g=20 MSCAN 26 24 MSCAN 29 24 MSCAN 34 24 i= * SCAN 42 24 SCAN 19 24 SCAN 15 24 SBF 26 24 SBF 30 24 SBF 34 24 PSBF 26 24 PSBF 42 24 PSBF 33 24 Drum Request Service Bulk Service Core Usage 6=0.50 FIFO 24 FIFO 24 FIFO 3 24 g=50 . MSCAN 25 24 MSCAN 30 24 MSCAN 36 24 i= * SCAN 45 24 SCAN 15 24 SCAN 12 24 SBF 25 24 SBF 30 24 SBF 36 24 PSBF 25 24 PSBF 45 24 PSBF 33 24 Drum Performance Comparisons Summing over i Table C.1a (cont. ). 165 Drum Request Service Bulk Service Core Usage 6=1.00 FIPO 24 PIFO 24 FIPO 32 24 g= 2 MSCAN 26 24 MSCAN 21 24 MSCAN 33 24 i= * SCAN 41 24 SCAN 28 24 SCAN 5 24 SBF 27 24 SBF 31 24 SBP 33 24 PSBP 26 24 PSBF 40 24 PSBP 17 24 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 24 FIFO 24 PIFO 19 24 g= 5 MSCAN 25 24 MSCAN 24 24 MSCAN 38 24 i= * SCAN 45 24 SCAN 21 24 SCAN 5 24 SBP 25 24 SBF 32 24 SBF 38 24 PSBP 25 24 PSBF 43 24 PSBF 20 24 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 24 FIFO 21 PIFO 14 24 g=10 MSCAN 25 24 MSCAN 26 24 MSCAN 39 24 i= * SCAN 45 24 SCAN 17 24 SCAN 5 24 SBP 25 24 SBF 32 24 SBF 39 24 PSBP 25 24 PSBF 45 24 PSBF 23 24 Drum Request Service Bulk Service Core Usage 6=1.00 PIFO 24 FIFO 24 FIPO 14 24 g=20 MSCAN 25 24 MSCAN 29 24 MSCAN 36 24 i= * SCAN 45 24 SCAN 15 24 SCAN 6 24 SBP 25 24 SBF 31 24 SBF 37 24 PSBP 25 24 PSBF 45 24 PSBF 27 24 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 24 FIPO 24 FIFO 9 24 g=50 MSCAN 26 24 MSCAN 30 24 MSCAN 38 24 i= * SCAN 45 24 SCAN 12 24 SCAN 8 24 SBF 26 24 SBP 32 24 SBF 38 24 PSBF 23 24 PSBF 46 24 PSBF 27 24 Drum Performance Comparisons Summing over i Table C.1a (cont.). 166 Drum Request Service Bulk Service Core Osage 6=2.00 PIFO 17 FIFO 4 17 FIFO 21 17 g= 2 MSCAN 18 17 MSCAN 13 17 MSCAN 23 17 i= * SCAN 34 20 SCAN 21 20 SCAN 10 20 SBP 18 17 SBF 23 17 SBF 23 17 PSBF 18 17 PSBF 27 17 PSBF 11 17 Dram Bequest Service Bulk Service Core Osage 6=2.00 PIFO 17 FIFO 3 17 FIFO 21 17 g= 5 MSCAN 17 17 MSCAN 15 17 MSCAN 22 17 i= * SCAN 37 20 SCAN 19 20 SCAN 12 20 SBP 17 17 SBF 22 17 SBF 22 17 PSBP 17 17 PSBF 29 17 PSBF 11 17 Drum Request Service Bulk Service Core Osage 6=2.00 PIPO 20 FIFO 3 20 FIFO 16 20 g=10 MSCAN 21 20 MSCAN 20 20 MSCAN 32 20 i= * SCAN 37 20 SCAN 10 20 SCAN 3 20 SBP 21 20 SBF 31 20 SBF 32 20 PSBF 21 20 PSBF 36 20 PSBP 17 20 Drum Request Service Bulk Service Core Osage 6=2.00 PIFO 20 FIFO 4 20 FIFO 20 20 g=20 MSCAN 21 20 MSCAN 21 20 MSCAN 27 20 i= * SCAN 37 20 SCAN 9 20 SCAN 6 20 SBF 21 20 SBF 30 20 SBF 27 20 PSBP 21 20 PSBF 36 20 PSBF 20 20 Drum Request Service Bulk Service Core Osage 6=2.00 PIFO 14 FIFO 3 14 FIPO 9 14 g=50 MSCAN 13 14 MSCAN 13 14 MSCAN 18 14 i= * SCAN 29 16 SCAN 10 16 SCAN 7 16 N SBF 19 16 SBF 24 16 SBF 26 16 PSBF 13 14 PSBF 24 14 PSBF 14 14 Drum Performance Comparisons Summing over i Table C.1a (cont.) . 167 Disk Request Service Bulk Service Core Osage 6=0.25 FIFO 23 FIFO 23 FIFO 14 23 g= 2 HSCAN 30 24 HSCAN 25 24 HSCAN 40 24 i= * SCAN 45 24 SCAN 40 24 SCAN 14 24 SBF 30 24 SBF 32 24 SBF 40 24 PSBF 13 23 PSBF 21 23 PSBF 10 23 Disk Request Service Bulk Service Core Usage 6=0.25 FIFO 24 FIFO 24 FIFO 7 24 g= 5 HSCAN 30 2 4 HSCAN 22 24 HSCAN 39 24 i= * SCAN 45 24 SCAN 28 24 SCAN 12 24 SBF 30 24 SBF 33 24 SBF 39 24 PSBF 15 24 PSBF 37 24 PSBF 23 24 Disk Request Service Bulk Service Core Usage 6=0.25 FIFO 24 FIFO 24 FIFO 5 24 g=10 MSCAN 29 24 HSCAN 23 24 HSCAN 39 24 i= * SCAN 45 24 SCAN 21 24 SCAN 12 24 SBF 29 24 SBF 33 24 SBF 39 24 PSBF 17 24 PSBF 43 24 PSBF 25 24 Disk Request Service Bulk Service Core Usage 6=0.25 FIFO 24 FIFO 24 FIFO 2 24 g=20 MSCAN 27 24 HSCAN 25 24 HSCAN 36 24 i= * SCAN 45 24 SCAN 20 24 SCAN 17 24 SBF 27 24 SBF 32 24 SBF 36 24 PSBF 21 24 PSBF 43 24 PSBF 29 24 Disk Request Service Bulk Service Core Usage 6=0.25 PIFO 24 FIFO 24 FIFO 24 g=50 HSCAN 29 24 HSCAN 27 24 HSCAN 38 24 i= * SCAN 45 24 SCAN 17 24 SCAN 16 24 SBF 29 24 SBF 31 24 SBF 38 24 PSBF 17 24 PSBF 45 24 PSBF 28 24 Disk Performance Comparisons Summing over i Table C. 1b. 168 Disk Request Service Bulk Service Core Osage 6=0.50 PIPO 21 FIFO 21 FIFO 12 21 g= 2 MSCAN 24 21 MSCAN 20 21 MSCAN 33 21 i= * SCAN 45 24 SCAN 39 24 SCAN 19 24 SBP 25 21 SBF 21 21 SBF 33 21 PSBP 14 21 PSBP 22 21 PSBP 11 21 Disk Request Service Bulk Service Core Osage 6=0.50 PIFO 23 FIFO 23 FIFO 6 23 g= 5 MSCAN 30 24 MSCAN 24 24 MSCAN 39 24 i= * SCAN 45 24 SCAN 26 24 SCAN 14 24 SBP 30 24 SBF 36 24 SBF 39 24 PSBP 13 23 PSBP 32 23 PSBF 20 23 Disk Request Service Bulk Service Core Usage 6=0.50 FIFO 24 FIFO 24 FIFO 5 24 g=10 MSCAN 29 24 MSCAN 22 24 MSCAN 39 24 i= * SCAN 45 24 SCAN 20 24 SCAN 11 24 SBP 29 24 SBF 35 24 SBF 39 24 PSBP 17 24 PSBF 43 24 PSBF 26 24 Disk Request Service Bulk Service Core Usage 6=0.50 FIFO 24 FIFO 24 FIFO 2 24 g=20 MSCAN 28 24 MSCAN 25 24 MSCAN 38 24 i= * SCAN 45 24 SCAN 20 24 SCAN 14 24 SBF 28 24 SBF 32 24 SBF 38 24 PSBP 19 24 PSBP 43 24 PSBF 28 24 Disk Request Service Bulk Service Core Osage 6=0.50 FIFO 23 FIFO 23 FIFO 1 23 g=50 MSCAN 28 24 MSCAN 28 24 MSCAN 36 24 i= * SCAN 48 24 SCAN 18 2<4 SCAN 16 24 SBF 28 24 SBF 34 24 SBP 39 24 PSBP 14 23 PSBF 38 23 PSBF 26 23 Disk Performance Comparisons Summing over i Table C. 1b (cont.). 169 Disk Request Service Bulk Service Core Usage 6=1.00 FIFO 17 FIFO 17 FIFO 17 17 g= 2 MSCAN 20 17 MSCAN 14 17 HSCAN 24 17 i= * SCAN 37 20 SCAN 29 20 SCAN 15 20 SBF 20 17 SBF 22 17 SBF 24 17 PSBF 11 17 PSBF 23 17 PSBF 8 17 Disk Request Service Bulk Service Core Osage 6=1.00 PIFO 17 FIFO 17 FIFO 9 17 g= 5 MSCAN 19 17 MSCAN 15 17 HSCAN 26 17 i= * SCAN 40 20 SCAN 22 20 SCAN 14 20 SBF 19 17 SBF 23 17 SBF 26 17 PSBF 10 17 PSBF 28 17 PSBF 13 17 Disk Request Service Bulk Service Core Usage 6=1.00 FIFO 21 FIFO 21 FIFO 7 21 g=10 HSCAN 25 21 MSCAN 19 21 HSCAN 33 21 i= * SCAN 46 24 SCAN 23 24 SCAN 16 24 SBF 25 21 SBF 30 21 SBF 33 21 PSBF 12 21 PSBF 36 21 PSBF 19 21 Disk Request Service Bulk Service Core Usage 6=1.00 FIFO 21 FIFO 21 FIFO 5 21 g=20 MSCAN 23 21 MSCAN 22 21 HSCAN 31 21 i- * SCAN 45 24 SCAN 23 24 SCAN 18 24 SBF 23 21 SBF 27 21 SBF 31 21 PSBF 17 21 PSBF 36 21 PSBF 23 21 Disk Request Service Bulk Service Core Usage 6=1.00 FIFO 15 FIFO 15 FIFO 1 15 g=50 MSCAN 18 16 HSCAN 20 16 MSCAN 27 16 i= * SCAN 32 16 SCAN 11 16 SCAN 12 16 SBF 13 15 SBF 15 15 SBF 19 15 PSBF 15 16 PSBF 32 16 PSBF 19 16 Disk Performance Comparisons Summing over i Table C.1b (cont. ). 170 Disk Request Service Bulk Service Core Usage 6=2.00 FIFO 12 FIFO 2 12 FIFO 16 12 g= 2 HSCAN 13 12 HSCAN 8 12 HSCAN 17 12 i= * SCAN 21 12 SCAN 14 12 SCAN 3 12 SBF 13 12 SBF 16 12 SBF 17 12 PSBF 13 12 PSBF 20 12 PSBF 7 12 Disk Request Serv ice Bulk Service Core Usage 6=2.00 FIFO 12 FIFO 12 FIFO 9 12 g= 5 HSCAN 13 12 HSCAN 11 12 HSCAN 20 12 i= * SCAN 24 12 SCAN 10 12 SCAN 2 12 SBF 13 12 SBF 18 12 SBF 20 12 PSBF 10 12 PSBF 21 12 PSBF 9 12 Disk Request Service Bulk Service Core Usage 6=2.00 PIFO 13 FIFO 13 FIFO 8 13 g=10 HSCAN 15 13 HSCAN 12 13 HSCAN 20 13 i= * SCAN 30 16 SCAN 16 16 SCAN 10 16 SBF 14 13 SBF 18 13 SBF 20 13 PSBF 9 13 PSBF 22 13 PSBF 10 13 Disk Request Service Bulk Service Core Usage 6=2.00 PIFO 13 FIFO 13 FIFO 8 13 g=20 HSCAN 14 13 HSCAN 13 13 HSCAN 16 13 i= * SCAN 29 16 SCAN 17 16 SCAN 13 16 SBF 13 13 SBF 15 13 SBF 16 13 PSBF 12 13 PSBF 23 13 PSBF 15 13 Disk Request Service Bulk Service Core Usage 6=2.00 FIFO 11 FIFO 1 1 FIFO 3 11 g=50 HSCAN 8 11 HSCAN 10 11 HSCAN 13 11 i= * SCAN 24 12 SCAN 8 12 SCAN 7 12 SBF 13 12 SBF 16 12 SBF 21 12 PSBF 13 12 PSBF 24 12 PSBF 14 12 Disk Performance Comparisons Summing over i Table C. 1b (cont.). 171 Drum Request Service Bulk Service Core Osage 6=0.25 FIFO 20 FIFO 20 FIFO 4 20 g= * MSCAN 25 20 MSCAN 25 20 MSCAN 24 20 i=.05 SCAN 25 20 SCAN 25 20 SCAN 24 20 SBF 25 20 SBF 25 20 SBF 24 20 PSBF 25 20 PSBF 25 20 PSBF 24 20 Drum Request Service Bulk Service Core Osage 6=0.25 FIFO 20 FIFO 20 FIFO 2 20 g= * MSCAN 22 20 MSCAN 24 20 MSCAN 25 20 i=.15 SCAN 34 20 SCAN 25 20 SCAN 24 20 SBF 22 20 SBF 25 20 SBF 25 20 PSBF 22 20 PSBF 26 20 PSBF 24 20 Drum Request Service Bulk Service Core Usage 6=0-25 FIFO 20 FIFO 20 FIFO 4 20 g= * MSCAN 21 20 MSCAN 23 20 MSCAN 29 20 i=.2 5 SCAN 38 20 SCAN 23 20 SCAN 16 20 SBF 21 20 SBF 26 20 SBF 29 20 PSBF 20 20 PSBF 28 20 PSBF 22 20 Drum Request Service Bulk Service Core Usage 6=0.25 FIFO 20 FIFO 20 FIFO 5 20 g= * MSCAN 20 20 MSCAN 23 20 MSCAN 29 20 i=-35 SCAN 40 20 SCAN 23 20 SCAN 13 20 SBF 20 20 SBF 23 20 SBF 29 20 PSBF 20 20 PSBF 31 20 PSBF 24 20 Drum Request Service Bulk Service Core Usage 6=0.25 FIFO 20 FIFO 20 FIFO 3 20 g= * MSCAN 20 20 MSCAN 21 20 MSCAN 31 20 i=.45 SCAN 40 20 SCAN 22 2C SCAN 10 20 SBF 20 20 SBF 22 20 SBF 31 20 PSBF 20 20 PSBF 35 20 PSBF 25 20 Drum Request Service Bulk Service Core Osage 6=0.25 FIFO 20 FIFO 20 FIFO 7 20 g= ♦ MSCAN 20 20 MSCAN 20 20 MSCAN 30 20 i=.55 SCAN 40 20 SCAN 22 20 SCAN 7 20 SBF 20 20 SBF 21 20 SBF 30 20 PSBF 20 20 PSBF 37 20 PSBF 26 20 Drum Performance Comparisons Summing over g Table C. 2a. 172 Drum Bequest Service Bulk Service Core Usaqe 6=0.50 FIFO 20 PIFO 20 FIPO 4 20 g= * HSCAN 25 20 MSCAN 25 20 MSCAN 24 20 i=-05 SCAN 25 20 SCAN 25 20 SCAN 24 20 SBP 25 20 SBP 25 20 SBF 24 20 PSBF 25 20 PSBP 25 20 PSBF 24 20 Drum Request Serv ice Bulk Service Core Usaqe 6=0.50 PIFO 20 FIFO 20 PIFO 5 20 g= * MSCAN 22 20 MSCAN 24 20 MSCAN 27 20 i=. 15 SCAN 34 20 SCAN 20 20 SCAN 16 20 SBP 22 20 SBP 25 20 SBF 27 20 PSBP 22 20 PSBP 31 20 PSBP 25 20 Drum Request Service Bulk Service Core Usage 6=0.50 PIPO 20 PIFO 20 PIFO 7 20 g= * MSCAN 20 20 MSCAN 22 20 MSCAN 30 20 i=.25 SCAN 39 20 SCAN 19 20 SCAN 8 20 SBP 20 20 SBF 24 20 SBF 30 20 PSBP 21 20 PSBP 35 20 PSBF 25 20 Drum Request Service Bulk Service Core Usage 6=0.50 FIPO 20 FIFO 20 FIFO 11 20 g= * MSCAN 20 20 MSCAN 21 20 MSCAN 30 20 i=.35 SCAN 40 20 SCAN 17 20 SCAN 4 20 SBP 20 20 SBF 23 20 SBF 30 20 PSBF 20 20 PSBF 39 20 PSBF 25 20 Drum Request Service Bulk Service Core Usage 6=0.50 FIFO 20 FIFO 20 FIFO 13 20 g= * MSCAN 20 20 MSCAN 21 20 MSCAN 32 20 i=.4 5 SCAN 40 20 SCAN 17 20 SCAN 2 20 SBP 20 20 SBF 23 20 SBF 32 20 PSBF 20 20 PSBF 39 20 PSBP 21 20 Drum Request Service Bulk Service Core Usaqe 6=0.50 FIFO 20 FIFO 20 FIFO 14 20 g= * MSCAN 20 20 MSCAN 21 20 HSCAN 33 20 i=-55 SCAN 40 20 SCAN 17 20 SCAN 2 20 SBF 20 20 SBF 24 20 SBF 33 20 PSBF 20 20 PSBF 38 20 PSBF 18 20 Drum Performance Comparisons Summing over g Table C.2a (cont.) . 173 Drum Reguest Service Bulk Service Core Usage 6=1.00 FIPO 20 FIFO 20 FIFO 8 20 g= * MSCAN 25 20 MSCAN 26 20 MSCAN 24 20 i=.05 SCAN 25 20 SCAN 22 20 SCAN 21 20 SBF 25 20 SBF 26 20 SBF 24 20 PSBP 25 20 PSBF 26 20 PSBF 23 20 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 20 FIFO 20 FIFO 10 20 g* * MSCAN 21 20 MSCAN 23 20 MSCAN 29 20 i=-15 SCAN 37 20 SCAN 16 20 SCAN 5 20 SBF 21 20 SBF 24 20 SBF 29 20 PSBF 21 20 PSBF 37 20 PSBF 27 20 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 20 FIFO 2 FIFO 16 20 g= * MSCAN 20 20 MSCAN 23 20 MSCAN 32 20 i=-25 SCAN 39 20 SCAN 13 20 SCAN 1 20 SBF 21 20 SBF 24 20 SBF 32 20 PSBF 20 20 PSBF 40 20 PSBF 19 20 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 20 FIFO 20 FIFO 17 20 g= * MSCAN 20 20 MSCAN 22 20 MSCAN 33 20 i=.35 SCAN UO 20 SCAN 13 20 SCAM 20 SBF 20 20 SBF 26 20 SBF 33 20 PSBF 20 20 PSBF 39 20 PSBF 17 20 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 20 FIFO 20 FIFO 18 20 g= * MSCAN 20 20 MSCAN 20 20 MSCAN 34 20 i=-45 SCAN 40 20 SCAN 13 20 SCAN 20 SBF 20 20 SBF 28 20 SBF 34 20 PSBF 20 20 PSBF 39 20 PSBF 14 20 Drum Request Service Bulk Service Core Usage 6=1.00 FIFO 20 FIFO 20 FIFO 19 20 g= * MSCAN 21 20 MSCAN 16 20 MSCAN 32 20 i=.55 SCAN UO 20 SCAN 16 20 SCAN 2 20 SBF 21 20 SBF 30 20 SBF 33 20 PSBF 18 20 PSBF 38 20 PSBF 14 20 Drum Performance Comparisons Summing over g Table C.2a (cont. ). 174 Drum Request Service Bulk Service Core Osage 6=2.00 FIFO 20 FIFO 20 FIFO 17 20 g = * MSCAN 25 20 MSCAN 25 20 MSCAN 24 20 i=.05 SCAN 25 20 SCAN 18 20 SCAN 12 20 SBF 25 20 SBF 27 20 SBF 24 20 PSBF 25 20 PSBF 30 20 PSBF 23 20 Drum Request Service Bulk Service Core Osage 6=2.00 FIFO 20 FIFO 5 20 FIFO 23 20 g= * MSCAN 21 20 MSCAN 23 20 MSCAN 29 20 i=. 15 SCAN 37 20 SCAN 8 20 SCAN 20 SBF 21 20 SBF 24 20 SBF 29 20 PSBF 21 20 PSBF 40 20 PSBF 19 20 Drum Request Service Bulk Service Core Usage 6=2.00 FIFO 20 FIFO 7 20 FIFO 25 20 g* * MSCAN 20 20 MSCAN 17 20 MSCAN 30 20 i=.25 SCAN 40 20 SCAN 7 20 SCAN 20 SBF 20 20 SBF 30 20 SBF 30 20 PSBF 20 20 PSBF 39 20 PSBF 15 20 Drum Request Service Bulk Service Core Usage 6=2.00 FIFO 18 FIFO 5 18 FIFO 22 18 g= * MSCAN 16 18 MSCAN 10 18 MSCA1 25 18 i=.35 SCAN 40 20 SCAN 15 20 SCAN 6 20 SBF 22 20 SBF 35 20 SBF 33 20 PSBF 16 18 PSBF 29 18 PSBF 8 18 Drum Request Service Bulk Service Core Usage 6=2.00 FIFO 10 FIFO 10 FIFO 10 g= * MSCAN 6 10 MSCAN 7 10 MSCAN 14 10 i=.45 SCAN 32 16 SCAN 21 16 SCAN 20 16 SBF 8 10 SBF 14 10 SBF 14 10 PSBF 8 10 PSBF 14 10 PSBF 8 10 Drum Request Service Bulk Service Core Usage 6=2.00 FIFO FIFO FIFO g= * MSCAN MSCAN MSCAN i=.55 SCAN SCAN SCAN SBF SBF SBF PSBF PSBF PSBF Drum Performance Comparisons Summing over Table C.2a (cont.). 175 Disk Request Service Bulk Service Core Usage 6=0.25 PIFO 20 FIFO 20 FIFO 1 20 9 « * MSCAN 25 20 MSCAN 25 20 MSCAN 25 20 i=.05 SCAN 25 20 SCAN 25 20 SCAN 25 20 SBP 25 20 SBF 25 20 SBF 25 20 PSBF 25 20 PSBF 25 20 PSBF 24 20 Disk Request Service Bulk Service Core Usage 6=0.25 FIPO 20 FIFO 20 FIFO 2 20 g- * MSCAN 22 20 MSCAN 23 20 MSCAN 30 20 i=. 15 SCAN UO 20 SCAN 19 20 SCAN 16 20 SBF 22 20 SBF 26 20 SBF 30 20 PSBF 16 20 PSBF 32 20 PSBF 22 20 Disk Request Service Bulk Service Core Usage 6=0.25 FIFO 20 FIFO 20 FIFO 5 20 g= * MSCAN 24 20 MSCAN 21 20 MSCAN 33 20 i=.25 SCAN UO 20 SCAN 19 20 SCAN 9 20 SBF 24 20 SBF 25 20 SBF 33 20 PSBF 12 20 PSBF 35 20 PSBF 20 20 Disk Request Service Bulk Service Core Usage 6=0.25 FIFO 20 FIFO 20 FIFO 9 20 g= * MSCAN 24 20 MSCAN 19 20 MSCAN 34 20 i=-35 SCAN 40 20 SCAN 20 20 SCAN 5 20 SBF 24 20 SBF 26 20 SBF 34 20 PSBF 12 20 PSBF 35 20 PSBF 18 20 Disk Request Service Bulk Service Core Usage 6=0.25 FIFO 20 FIFO 20 FIFO 11 20 g= * MSCAN 25 20 MSCAN 17 20 MSCAN 35 20 i=.45 SCAN 40 20 SCAN 20 20 SCAN 4 20 SBF 25 20 SBF 29 20 SBF 35 20 PSBF 10 20 PSBF 34 20 PSBF 15 20 Disk Request Service Bulk Service Core Usage 6=0.25 FIFO 19 FIFO 19 FIFO 19 g= * MSCAN 25 20 MSCAN 17 20 MSCAN 35 20 i=.55 SCAN 40 20 SCAN 23 20 SCAN 12 20 SBF 25 20 SBF 30 20 SBF 35 20 PSBF 8 19 PSBF 28 19 PSBF 16 19 Disk Performance Comparisons Summing over g Table C. 2b. 176 Disk Reguest Service Bulk Service Core Usage 6=0.50 FIPO 20 FIFO 20 PIFO 2 20 g= * HSCAN 24 20 MSCAN 25 20 HSCAN 25 20 i=.05 SCAN 28 20 SCAN 24 20 SCAN 24 20 SBP 24 20 SBF 25 20 SBP 25 20 PSBP 24 20 PSBP 26 20 PSBP 24 20 Disk Request Service Bulk Service Core Usage 6=0.50 PIPO 20 PIFO 20 PIPO 4 20 g= * HSCAN 21 20 MSCAN 23 20 HSCAN 31 20 i=.15 SCAN 40 20 SCAN 17 20 SCAN 10 20 SBF 22 20 SBP 25 20 SBP 31 20 PSBP 17 20 PSBF 35 20 PSBF 24 20 Disk Request Service Bulk Service Core Osage 6=0.50 FIFO 20 PIFO 20 FIPO 9 20 g= * MSCAN 24 20 MSCAN 21 20 HSCAN 33 20 i=.25 SCAN 40 20 SCAN 17 20 SCAN 5 20 SBF 24 20 SBF 26 20 SBP 33 20 PSBP 12 20 PSBF 36 20 PSBP 20 20 Disk Request Service Bulk Service Core Osaqe 6=0.50 PIFO 20 FIPO 20 PIPO 11 20 g= * MSCAN 25 20 MSCAN 17 20 HSCAN 35 20 i=.35 SCAN 40 20 SCAN 19 20 SCAN 4 20 SBF 25 20 SBF 29 20 SBP 35 20 PSBP 10 20 PSBF 35 20 PSBP 15 20 Disk Request Service Bulk Service Core Usage 6=0.50 FIFO 20 PIFO 20 FIFO 20 g= ♦ MSCAN 25 20 MSCAN 16 20 HSCAN 34 20 i=.45 SCAN 40 20 SCAN 21 20 SCAN 11 20 SBF 25 20 SBF 31 20 SBP 35 20 PSBP 10 20 PSBF 32 20 PSBP 20 20 Disk Request Service Bulk Service Core Usage 6=0.50 PIFO 15 FIFO 15 FIPO 15 g= ♦ MSCAN 20 17 MSCAN 17 17 HSCAN 27 17 i=.55 SCAN 40 20 SCAN 25 20 SCAN 20 20 SBF 20 17 SBF 28 17 SBF 29 17 PSBP 4 15 PSBF 14 15 PSBF 8 15 Disk Performance Comparisons Summing over Table C.2b (cont. ) . 177 Disk Request Service Bulk Service Core Osage 6=1.00 PIFO 20 FIFO 20 FIFO 3 20 g« * MSCAN 23 20 MSCAN 24 20 MSCAN 24 20 i=.05 SCAN 32 20 SCAN 21 20 SCAN 24 20 SBF 23 20 SBF 25 20 SBF 25 20 PSBF 22 20 PSBF 30 20 PSBF 24 20 Disk Request Service Bulk Service Core Usage 6=1.00 FIPO 20 FIFO 20 FIFO 10 20 g- * MSCAN 23 20 MSCAN 22 20 MSCAN 33 20 i=-15 SCAN 40 20 SCAN 15 20 SCAN 6 20 SBF 23 20 SBF 25 20 SBF 33 20 PSBF 14 20 PSBF 38 20 PSBF 18 20 Disk Request Service Bulk Service Core Osage 6=1.00 FIPO 20 FIFO 2 FIFO 12 20 g= * MSCAN 24 20 MSCAN 19 20 MSCAN 34 20 i=.25 SCAN 40 20 SCAN 15 20 SCAN 4 20 SBP 24 20 SBF 28 20 SBF 33 20 PSBF 12 20 PSBF 38 20 PSBF 17 20 Disk Request Service Bulk Service Core Osage 6=1.00 FIFO 19 FIFO 19 FIPO 14 19 g= * MSCAN 25 20 MSCAN 18 20 MSCAN 36 20 i=.3 5 SCAN 40 20 SCAN 19 20 SCAN 5 20 SBF 20 19 SBF 26 19 SBF 28 19 PSBF 13 20 PSBF 35 20 PSBF 15 20 Disk Request Service Bulk Service Core Usage 6=1.00 FIPO 10 FIFO 10 FIFO 10 g= * MSCAN 10 10 MSCAN 7 10 MSCAN 14 10 i=-45 SCAN 32 16 SCAN 22 16 SCAN 20 16 SBP 10 10 SBF 13 10 SBF 14 10 PSBP 4 10 PSBF 14 10 PSBF 8 10 Disk Request Service Bulk Service Core Usage 6=1.00 PIFO 2 FIFO 2 FIFO 2 g= * MSCAN 2 MSCAN 2 MSCAN 2 i=-55 SCAN 16 8 SCAN 16 8 SCAN 16 8 SBF 2 SBF 2 SBF 2 PSBF 2 PSBP 2 PSBF 2 Disk Performance Comparisons Summing over g Table C.2b (cont.). 178 Disk Request Service Bulk Service Core Usage 6=2.00 FIPO 20 FIPO 20 FIFO 8 20 g= * fISCAN 23 20 MSCAN 22 20 MSCAN 28 20 i=.05 SCAM 32 20 SCAN 17 20 SCAN 13 20 SBP 23 20 SBP 26 20 SBF 28 20 PSBP 22 20 PSBP 35 20 PSBF 23 20 Disk Request Service Bulk Service Core Usaqe 6=2-00 PIPO 20 FIFO 1 20 FIFO 17 20 g= * MSCAN 21 20 MSCAN 21 20 MSCAN 33 20 i=. 15 SCAN 40 20 SCAN 13 20 SCAN 2 20 SBP 20 20 SBF 26 20 SBF 33 20 PSBF 19 20 PSBF 39 20 PSBF 15 20 Disk t Request Service Bulk Service Core Osage 6=2-00 PIPO 19 FIFO 1 19 FIFO 19 19 g= * MSCAN 19 19 MSCAN 11 19 MSCAN 25 19 i=-25 SCAN 40 20 SCAN 19 20 SCAN 4 20 SBP 23 20 SBF 31 20 SBP 33 20 PSBP 16 20 PSBF 36 20 PSBF 17 20 Disk Request Service Bulk Service Core Osage 6=2.00 PIPO 2 FIFO 2 FIFO 2 g= * MSCAN 2 MSCAN 2 MSCAN 2 i=-35 SCAN 16 8 SCAN 16 8 SCAN 16 8 SBP 2 SBF 2 SBF 2 PSBP 2 PSBF 2 PSBF 2 Disk Request Service Bulk Service Core Usaqe 6=2.00 PIPO FIFO FIFO g= * MSCAN MSCAN MSCAN i=.45 SCAN SCAN SCAN SBP SBF SBF PSBP PSBF PSBF Disk Request Service Bulk Service Core Usaqe 6=2.00 PIPO FIFO FIPO g= * MSCAN MSCAN MSCAN i=.55 SCAN SCAM SCAN SBP SBF SBP PSBF PSBP PSBF Disk Performance Comparisons Summinq over q Table C.2b (cont.). 179 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 16 FIFO 16 16 g= 2 HSCAN 20 16 HSCAN 20 16 HSCAN 17 16 i=-05 SCAN 20 16 SCAN 20 16 SCAN 14 16 SBP 20 16 SBF 20 16 SBF 17 16 PSBP 20 16 PSBP 20 16 PSBF 16 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 1 16 FIFO 16 16 g= 2 HSCAN 20 16 HSCAN 16 16 HSCAN 21 16 i=. 15 SCAN 20 16 SCAN 19 16 SCAN 7 16 SBP 20 16 SBF 18 16 SBF 21 16 PSBP 20 16 PSBF 26 16 PSBF 15 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 PIFO 2 16 FIFO 19 16 g= 2 HSCAN 17 16 HSCAN 14 16 HSCAN 24 16 i=-25 SCAN 28 16 SCAN 17 16 SCAN 4 16 SBP 18 16 SBF 21 16 SBF 24 16 PSBP 17 16 PSBF 26 16 PSBF 9 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 1 16 FIFO 21 16 g= 2 HSCAN 16 16 HSCAN 11 16 HSCAN 24 16 i=.35 SCAN 32 16 SCAN 20 16 SCAN 3 16 SBP 16 16 SBF 20 16 SBF 24 16 PSBP 16 16 PSBP 28 16 PSBF 8 16 Drum Request Service Bulk Service Core Usage 6= * FIFO 13 FIFO 13 FIFO 14 13 g= 2 HSCAN 12 13 HSCAN 9 13 HSCAN 19 13 i=.45 SCAN 32 16 SCAN 25 16 SCAN 10 16 SBF 12 13 SBF 13 13 SBF 19 13 PSBP 12 13 PSBF 21 13 PSBF 6 13 Drum Request Service Bulk Service Core Usage 6= * FIFO 12 FIFO 12 FIFO 17 12 q= 2 HSCAN 12 12 HSCAN 8 12 HSCAN 18 12 i=.55 SCAN 24 12 SCAN 19 12 SCAN 1 12 SBF 12 12 SBF 14 12 SBF 18 12 PSBP 12 12 PSBP 19 12 PSBF 6 12 Drum Performance Comparisons Summing over Table C. 3a. 180 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 PIPO 16 FIFO 6 16 g= 5 HSCAN 20 16 HSCAN 20 16 HSCAN 19 16 i=.05 SCAN 20 16 SCAN 20 16 SCAN 18 16 SBP 20 16 SBP 20 16 SBP 19 16 PSBP 20 16 PSBP 20 16 PSBP 18 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 PIPO 1 16 FIFO 8 16 g= 5 HSCAN 16 16 HSCAN 19 16 HSCAN 22 16 i=- 15 SCAN 32 16 SCAN 16 16 SCAN 10 16 SBP 16 16 SBP 20 16 SBP 22 16 PSBP 16 16 PSBP 24 16 PSBF 18 16 Drum Request Service Bulk Service Core Usage 6* * PIPO 16 PIPO 1 16 PIPO 10 16 g= 5 HSCAN 16 16 HSCAN 17 16 HSCAN 25 16 i=.25 SCAN 32 16 SCAN 14 16 SCAN 4 16 SBP 16 16 SBP 21 16 SBF 25 16 PSBP 16 16 PSBP 27 16 PSBF 16 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 1 16 PIPO 13 16 g= 5 HSCAN 16 16 HSCAN 16 16 HSCAN 25 16 i=.35 SCAN 32 16 SCAN 14 16 SCAN 2 16 SBP 16 16 SBF 20 16 SBF 25 16 PSBP 16 16 PSBP 29 16 PSBP 15 16 Drum Request Service Bulk Service Core Usage 6* * PIPO 13 FIFO 13 PIPO 7 13 g= 5 HSCAN 12 13 HSCAN 12 13 HSCAN 20 13 i=.45 SCAN 32 16 SCAN 20 16 SCAN 9 16 SBP 12 13 SBF 15 13 SBP 20 13 PSBP 12 13 PSBF 21 13 PSBF 12 13 Drum Request Service Bulk Service Core Usage 6= * PIPO 12 FIFO 12 PIPO 10 12 g= 5 HSCAN 12 12 HSCAN 11 12 HSCAN 19 12 i=.55 SCAN 24 12 SCAN 12 12 SCAN 1 12 SBP 12 12 SBF 15 12 SBP 19 12 PSBP 12 12 PSBP 22 12 PSBF 11 12 Drum Performance Comparisons Summing over 6 Table C.3a (cont.). 181 Drum Request Service Bulk Service Core Osage 6= * PIPO 16 PIFO 16 FIFO 5 16 g=10 MSCAN 20 16 MSCAN 20 16 MSCAN 20 16 i=.05 SCAN 20 16 SCAN 18 16 SCAN 15 16 SBP 20 16 SBF 21 16 SBF 20 16 PSBP 20 16 PSBF 21 16 PSBF 20 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 1 16 PIPO 6 16 g=10 MSCAN 16 16 MSCAN 19 16 MSCAN 23 16 i«-15 SCAN 32 16 SCAN 13 16 SCAN 9 16 SBF 16 16 SBF 20 16 SBF 23 16 PSBP 16 16 PSBP 27 16 PSBF 19 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 1 16 FIFO 7 16 g=10 MSCAN 16 16 MSCAN 18 16 MSCAN 26 16 i=.25 SCAN 32 16 SCAN 12 16 SCAN 4 16 SBF 16 16 SBF 20 16 SBF 26 16 PSBP 16 16 PSBP 29 16 PSBF 17 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 1 16 FIFO 8 16 g=10 MSCAN 16 16 MSCAN 17 16 MSCAN 26 16 i=.35 SCAN 32 16 SCAN 12 16 SCAN 3 16 SBF 16 16 SBF 22 16 SBF 26 16 PSBP 16 16 PSBP 28 16 PSBF 17 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 16 FIFO 5 16 g=10 MSCAN 16 16 MSCAN 15 16 MSCAN 27 16 i=-45 SCAN 32 16 SCAN 12 16 SCAN u 16 SBF 16 16 SBF 23 16 SBF 27 16 PSBP 16 16 PSBF 30 16 PSBF 17 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 12 FIFO 12 FIFO 7 12 g=10 MSCAN 12 12 MSCAN 11 12 MSCAN 20 12 i=.55 SCAN 24 12 SCAN 10 12 SCAN 1 12 SBP 12 12 SBF 15 12 SBF 20 12 PSBP 12 12 PSBF 24 12 PSBF 12 12 Drum Performance Comparisons Summing over Table C.3a (cont.). 182 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 PIPO 16 PIPO 5 16 g=20 MSCAN 20 16 MSCAN 20 16 MSCAN 19 16 i=.05 SCAN 20 16 SCAM 18 16 SCAN 18 16 SBP 20 16 SBP 21 16 SBP 19 16 PSBP 20 16 PSBP 21 16 PSBP 19 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 PIPO 1 16 PIPO 6 16 g=20 MSCAN 18 16 MSCAN 20 16 MSCAN 21 16 i=. 15 SCAN 26 16 SCAN 12 16 SCAN 11 16 SBP 18 16 SBP 20 16 SBP 21 16 PSBP 18 16 PSBP 27 16 PSBP 21 16 Drum Request Service Bulk Service Core Usage 5= * PIPO 16 PIPO 1 16 PIPO 8 16 g=20 NSCAN 16 16 MSCAN 19 16 MSCAN 22 16 i=,25 SCAN 32 16 SCAN 11 16 SCAN 8 16 SBP 16 16 SBP 20 16 SBP 22 16 PSBP 16 16 PSBP 29 16 PSBP 20 16 Drum Bequest Service Bulk Service Core Usage 6= * PIPO 16 PIPO 2 16 PIPO 10 16 g=20 MSCAN 16 16 MSCAN 17 16 MSCAN 23 16 i=.35 SCAN 32 16 SCAN 10 16 SCAN 6 16 SBP 16 16 SBP 22 16 SBP 23 U PSBP 16 16 PSBP 29 16 PSBP 18 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 16 PIPO 16 PIPO a 16 g=20 MSCAN 16 16 MSCAN 18 16 MSCAN 26 16 i=.t»5 SCAN 32 16 SCAN 10 16 SCAN 6 16 SBP 16 16 SBP 21 16 SBP 26 16 PSBP 16 16 PSBP 31 16 PSBP 18 16 Drum Request Service Bulk Service Core Usage 6= * PIPO 12 PIFO 12 PIPO 5 12 g=20 MSCAN 12 12 MSCAN 13 12 MSCAN 18 12 i=,55 SCAN 24 12 SCAN 8 12 SCAN 3 12 SBP 12 12 SBP 15 12 SBP 19 12 PSBP 12 12 PSBP 24 12 PSBP 15 12 Drum Performance Comparisons Summing over Table C.3a (cont.) . 183 Drum Request Service Bulk Service Core Usage 6= * FIFO 16 FIFO 16 FIFO 1 16 g=50 MSCAN 20 16 MSCAN 21 16 MSCAN 21 16 i=.05 SCAN 20 16 SCAN 14 16 SCAN 16 16 SBF 20 16 SBF 21 16 SBF 21 16 PSBF 20 16 PSBF 24 16 PSBF 21 16 Drum Request Service Bulk Service Core Usage 6= * FIFO 16 FIFO 1 16 FIFO 4 16 g=50 MSCAN 16 16 MSCAN 20 16 MSCAN 23 16 i=. 15 SCAN 32 16 SCAN 9 16 SCAN 8 16 SBF 16 16 SBF 20 16 SBF 23 16 PSBF 16 16 PSBF 30 16 PSBF 22 16 Drum Request Service Bulk Service Core Usage 6= * FIFO 16 FIFO 2 16 FIFO 8 16 g=50 MSCAN 16 16 MSCAN 17 16 MSCAN 24 16 i=.25 SCAN 32 16 SCAN 8 16 SCAN 5 16 SBF 16 16 SBF 22 16 SBF 24 16 PSBF 16 16 PSBF 31 16 PSBF 19 16 Drum Request Service Bulk Service Core Usage 6= * FIPO 14 FIFO 14 FIFO 3 14 g=50 MSCAN 12 14 MSCAN 15 14 MSCAN 19 14 i=.35 SCAN 32 16 SCAN 12 16 SCAN 9 16 SBF 18 16 SBF 23 16 SBF 21 16 PSBF 12 14 PSBF 24 14 PSBF 16 14 Drum Request Service Bulk Service Core Usage 6= * FIFO 12 FIFO 12 FIFO 4 12 g=50 MSCAN 12 12 MSCAN 15 12 MSCAN 19 12 i=.45 SCAN 24 12 SCAN 6 12 SCAN 3 12 SBF 12 12 SBF 15 12 SBF 19 12 PSBF 12 12 PSBF 24 12 PSBF 15 12 Drum Request Service Bulk Service Core Usage 6* * FIFO 12 FIFO 12 FIFO 1 12 g=50 MSCAN 13 12 MSCAN 14 12 MSCAN 20 12 i=-55 SCAN 24 12 SCAN 6 12 SCAN 5 12 SBF 13 12 SBF 16 12 SBF 20 12 PSBF 10 12 PSBF 24 12 PSBF 14 12 Drum Performance Comparisons Summing over Table C.3a (cont. )• 18U Disk Request Service Bulk Service Core Usage 6* * . FIPO 16 FIPO 16 FIPO 10 16 g- 2 MSCAN 20 16 MSCAN 19 16 MSCAN 19 16 i=.05 SCAN 20 16 SCAN 19 16 SCAN 15 16 SBP 20 16 SBF 20 16 SBF 20 16 PSBP 20 16 PSBF 22 16 PSBP 16 16 Disk Request Service Bulk Service Core Usage 6= * FIPO 16 PIFO 1 16 FIFO 15 16 g= 2 MSCAN 18 16 MSCAN 17 16 MSCAI 26 16 i=.15 SCAN 32 16 SCAN 19 16 SCAN 6 16 SBP 19 16 SBF 20 16 SBF 26 16 PSBP 11 16 PSBF 23 16 PSBP 7 16 Disk Request Service Bulk Service Core Usage 6= * FIFO 16 FIFO 1 16 FIFO 18 16 g= 2 MSCAN 19 16 MSCAN 12 16 MSCAN 27 16 i=.25 SCAN 32 16 SCAN 24 16 SCAN 3 16 SBF 19 16 SBF 22 16 SBF 26 16 PSBP 10 16 PSBF 21 16 PSBF 6 16 Disk Request Service Bulk Service Core Usage 6= * FIPO 12 FIFO 12 FIPO 12 12 g= 2 MSCAN 15 12 MSCAN 9 12 MSCAN 21 12 i=. 35 SCAN 24 12 SCAN 20 12 SCAN 3 12 SBF 15 12 SBF 17 12 SBP 21 12 PSBP 6 12 PSBF 14 12 PSBP 3 12 Disk Request Service Bulk Service Core Osage 6= * PIFO 9 FIFO 9 FIFO 4 9 g= 2 MSCAN 10 9 MSCAN 6 9 MSCAN 14 9 i=-45 SCAN 24 12 SCAN 24 12 SCAN 12 12 SBF 10 9 SBF 12 9 SBF 14 9 PSBF 4 9 PSBP 6 9 PSBF 4 9 Disk Request Service Bulk Service Core Usage 6= * FIFO 4 FIFO g FIFO 4 g= 2 MSCAN 5 5 MSCAN 4 5 MSCAN 7 5 i=-55 SCAN 16 8 SCAN 16 8 SCAN 12 8 SBF 5 5 SBF 6 5 SBF 7 5 PSBF 4 PSBF 4 PSBF 4 Disk Performance Comparisons Summing over <5 Table C. 3b. 185 Disk Request Service Bulk Service Core Usage 6= * FIPO 16 FIFO 16 FIFO 2 16 g= 5 MSCAN 18 16 MSCAN 20 16 MSCAN 21 16 i=-05 SCAN 26 16 SCAN 19 16 SCAN 17 16 SBP 18 16 SBF 20 16 SBF 21 16 PSBP 18 16 PSBF 21 16 PSBF 19 16 Disk Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 16 FIFO 6 16 g= 5 MSCAN 19 16 MSCAN 17 16 MSCAN 26 16 i=-15 SCAN 32 16 SCAN 15 16 SCAN 6 16 SBP 19 16 SBF 21 16 SBF 26 16 PSBP 10 16 PSBF 27 16 PSBF 16 16 Disk Request Service Bulk Service Core Usage 6= * PIPO 16 FIFO 16 FIFO 10 16 g= 5 MSCAN 20 16 MSCAN 14 16 MSCAN 28 16 i=.25 SCAN 32 16 SCAN 13 16 SCAN 3 16 SBP 20 16 SBF 24 16 SBF 28 16 PSBP 8 16 PSBP 29 16 PSBF 11 16 Disk Request Service Bulk Service Core Usage 6= * PIPO 12 FIFO 12 FIFO 10 12 g= 5 MSCAN 15 12 MSCAN 9 12 MSCAN 21 12 i=.35 SCAN 24 12 SCAN 10 12 SCAN 12 SBP 15 12 SBF 20 12 SBF 21 12 PSBP 6 12 PSBF 21 12 PSBF 8 12 Disk Request Serv ice Bulk Service Core Usage 6= * PIPO 9 FIFO 9 FIFO 3 9 g= 5 MSCAN 10 9 MSCAN 6 9 MSCAN 14 9 i=-45 SCAN 24 12 SCAN 16 12 SCAN 10 12 SBP 10 9 SBF 12 9 SBF 14 9 PSBP 4 9 PSBF 14 9 PSBF 7 9 Disk Request Service Bulk Service Core Usage 6= * FIPO 7 FIFO 7 FIFO 7 g= 5 MSCAN 10 8 MSCAN 6 8 MSCAN 14 8 i=.55 SCAN 16 8 SCAN 13 8 SCAN 6 8 SBF 10 8 SBF 13 8 SBF 14 8 PSBP 2 7 PSBF 6 7 PSBF 4 7 Disk Performance Comparisons Summing over 6 Table C.3b (cont. ). 186 Disk Request Service Bulk Service Core Usage 6= * PIFO 16 PIFO 16 FIFO 1 16 g=10 NSCAN 20 16 MSCAN 19 16 NSCAN 21 16 i=,05 SCAN 22 16 SCAN 17 16 SCAN 17 16 SBP 20 16 SBF 21 16 SBF 21 16 PSBP 18 16 PSBF 23 16 PSBF 20 16 Disk Request Serv ice Bulk Service Core Usage 6= * PIPO 16 FIFO 16 FIFO 5 16 g=10 NSCAN 18 16 NSCAN 18 16 NSCAN 26 16 i=. 15 SCAN 32 16 SCAN 11 16 SCAN 5 16 SBP 17 16 SBF 20 16 SBF 26 16 PSBP 13 16 PSBF 31 16 PSBF 18 16 Disk Request Service Bulk Service Core Usage 6= * PIPO 16 PIFO 16 PIPO 9 16 g=10 NSCAN 20 16 NSCAN 14 16 NSCAN 28 16 i=.25 SCAN 32 16 SCAN 12 16 SCAN 2 16 SBP 20 16 SBF 23 16 SBF 28 16 PSBP 8 1*6 PSBP 31 16 PSBF 13 16 Disk Request Service Bulk Service Core Usage 6= * PIPO 13 PIFO 13 FIFO 7 13 g=10 MSCAN 15 13 NSCAN 10 13 NSCAN 21 13 i=-35 SCAN 32 16 SCAN 17 16 SCAN 9 16 SBP 15 13 SBF 18 13 SBF 21 13 PSBF 6 13 PSBP 23 13 PSBF 10 13 Disk Request Service Bulk Service Core Usage 6= * PIPO 12 FIFO 12 FIFO 3 12 g=10 MSCAN 15 12 NSCAN 9 12 NSCAN 21 12 i=.45 SCAN 24 12 SCAN 9 12 SCAN 4 12 SBP 15 12 SBF 20 12 SBF 21 12 PSBP 6 12 PSBF 22 12 PSBF 11 12 Disk Request Service Bulk Service Core Usage 6= * PIPO 9 FIFO 9 FIFO 9 g=10 NSCAN 10 9 NSCAN 6 9 NSCAN 14 9 i=.55 SCAN 24 12 SCAN 14 12 SCAN 12 12 SBP 10 9 SBF 14 9 SBF 14 9 PSBP 4 9 PSBF 14 9 PSBF 8 9 Disk Performance Comparisons Summing over 6 Table C.3b (cont.) . 187 Disk Request Service Bulk Service Core Usage 6= * FIFO 16 FIFO 16 FIFO 1 16 g=20 MSCAN 20 16 MSCAN 19 16 HSCAN 20 16 i=-05 SCAN 20 16 SCAN 18 16 SCAN 19 16 SBF 20 16 SBF 20 16 SBF 20 16 PSBF 20 16 PSBF 23 16 PSBF 20 16 Disk Request Service Bulk Service Core Usage 6= * FIFO 16 FIFO 16 FIFO 3 16 g=20 MSCAN 16 16 MSCAN 17 16 HSCAN 23 16 i=. 15 SCAN 32 16 SCAN 11 16 SCAN 11 16 SBF 16 16 SBF 21 16 SBF 23 16 PSBF 16 16 PSBF 31 16 PSBF 20 16 Disk Request Service Bulk Service Core Usage 5= * FIFO 16 FIFO 16 FIFO 7 16 g=20 HSCAN t7 16 HSCAN 17 16 HSCAN 23 16 i=,25 Scan 32 16 SCAN 11 16 SCAN 5 16 SBF 16 16 SBF 20 16 SBF 23 16 PSBF 15 16 PSBF 32 16 PSBF 22 16 Disk Request Service Bulk Service Core Usage 6= * FIFO 13 FIFO 13 FIFO 5 13 g=20 MSCAN 14 13 MSCAN 12 13 HSCAN 20 13 i=-35 SCAN 32 16 SCAN 17 16 SCAN 10 16 SBF 14 13 SBF 16 13 SBF 20 13 PSBF 8 13 PSBF 23 13 PSBF 13 13 Disk Request Service Bulk Service Core Usage 6= * FIFO 12 FIFO 12 FIFO 1 12 g=20 MSCAN 15 12 MSCAN 12 12 HSCAN 21 12 i=.45 SCAN 24 12 SCAN 9 12 SCAN 5 12 SBF 15 12 SBF 17 12 SBF 21 12 PSBF 6 12 PSBF 22 12 PSBF 12 12 Disk Request Service Bulk Service Core Usage 6= * PIFO 9 FIFO 9 FIFO 9 g=20 MSCAN 10 9 MSCAN 8 9 HSCAN 14 9 i=.55 SCAN 24 12 SCAN 14 12 SCAN 12 12 SBF 10 9 SBF 12 9 SBF 14 9 PSBF 4 9 PSBF 14 9 PSBF 8 9 Disk Performance Comparisons Summing over <$ Table C.3b (cont.). 188 Disk Request Service Bulk Service Core Osage 6= * PIFO 16 PIPO 16 FIFO 16 g=50 MSCAN 17 16 MSCAN 19 16 MSCAN 21 16 i=.05 SCAN 29 16 SCAN 14 16 SCAN 18 16 SBP 17 16 SBF 20 16 SBF 21 16 PSBP 17 16 PSBP 27 16 PSBF 20 16 Disk Bequest Service Bulk Service Core Usage 6= * PIFO 16 PIFO 16 FIFO 4 16 g=50 MSCAN 16 16 MSCAN 20 16 MSCAN 26 16 i=.15 SCAN 32 16 SCAN 8 16 SCAM 6 16 SBP 16 16 SBP 20 16 SBF 26 16 PSBP 16 16 PSBP 32 16 PSBF 18 16 Disk Request Service Bulk Service Core Usage 6= * PIPO 15 FIFO 15 FIFO 1 15 g=50 MSCAN 15 15 MSCAN 15 15 MSCAN 19 15 i=.25 SCAN 32 16 SCAN 10 16 SCAN 9 16 SBP 20 16 SBF 21 16 SBF 27 16 PSBP 11 16 PSBP 32 16 PSBF 22 16 Disk Request Service Bulk Service Core Usage 6 = * PIPO 11 FIFO 1 1 FIFO 11 g=50 MSCAN 15 12 MSCAN 14 12 MSCAN 22 12 i=. 35 SCAN 24 12 SCAN 10 12 SCAN 8 12 SBP 10 11 SBF 10 11 SBP 14 11 PSBP 9 12 PSBF 24 12 PSBP 14 12 Disk Request Service Bulk Service / Core Usage 6= * PIFO 8 FIFO 8 FIFO 8 g=50 MSCAN 10 8 MSCAN 7 8 MSCAN 13 8 i=- U5 SCAN 16 8 SCAN 5 6 SCAN 4 8 SBP 10 8 SBF 12 8 SBF 14 8 PSBP U 8 PSBF 16 8 PSBF 9 8 Disk Request Service Bulk Service Core Usage 6= * PIFO 7 FIFO 7 FIFO 7 g=50 MSCAN 10 8 MSCAN 10 8 MSCAN 13 8 i=.55 SCAN 16 8 SCAN 7 8 SCAN 6 8 SBF 10 8 SBF 13 8 SBF 15 8 PSBP 2 7 PSBF 8 7 PSBF 4 7 Disk Performance Comparisons Summing over <5 Table C.3b (cont.). 189 VITA J. Michael Hilner was born in Chicago, Illinois, on Jane 10, 1950. He received a B-S.E.E. from the Massachusetts Institute o£ Technology in June 1972. In September of that year he entered the University of Illinois and received an M.S. in Computer Science in August of 1975. He is a member of the Association of Computing Machinery- UBLIOGRAPHIC DATA .HEET 1. Report No. UIUCDCS-R-76-826 3. Recipient's Accession No. 5. Report Date September 1976 Title and Subtitle AN ANALYSIS OF ROTATIONAL STORAGE ACCESS SCHEDULING IN A MULTI PROGRAMMED INFORMATION RETRIEVAL SYSTEM 6. Author(s) James Michael Milner 8. Performing Organization Rept. No - UIUCDCS-R-76-826 Performing Organization Name and Address University of Illinois at Urbana-Champaign Department of Computer Science Urbana, Illinois 61801 10. Project/Task/Work Unit No. 11. Contract /Grant No. US NSF DCR73-07980 A02 2. Sponsoring Organization Name and Address National Science Foundation Washington, D. C. 13. Type of Report & Period Covered Doctoral - 1976 14. 5. Supplementary Notes 6. Abstracts In this thesis the effects of five secondary storage access scheduling policies are studied in the context of a multi programmed information retrieval system. Such systems are characterized by independent requests for groups of records from the disk or drum secondary storage device. Further processing of each request is blocked until all records of the group, which we term a bulk, are accessed. A model which captures the essential behavior of the class of systems under study is described. Important parameters of the model are determined from a study of an actual system, MEDLINE. The behavior of the model under each of the five scheduling policies is studied both analytically and via simulation. Results show unexpectedly poor performance by the commonly used SCAN scheduling policy. Better scheduling policies are defined and features which characterize good and bad policies are 7. Key Words and Document Analysis. 17o. Descriptors enumerated. Details of the MEDLINE study and the simulator are included in appendixes along with an atlas of simulation results. Computer system architecture Computer system simulation Disk scheduling Drum scheduling Information retrieval MEDLINE 7b. Identifiers/Open-Ended Terms 7e. COSATI Field/Group B. Availability Statement Release Unlimited 3HM NTIS-3B ( 10-70) 19. Security Class (This Report) UNCLASSIFIED 20. Security Class (This Page UNCLASSIFIED 21. No. of Pages 198 22. Price USCOMM-DC 40329-P71 if* \\ \9Tf aSKSSKT^ Internal report / 30112088402992 91 In .&$d ■ V ■ ■ I '->N> 3» HI ■ »i$5h JMpro M W YflnWBrrlM. BBBRH