In these experiments, the following system parameters are fixed: block size is 384 KByte, GSS is configured with a single group (g=1), and a single logical zone spans all 23 physical zones of each disk. We analyzed the performance of Mitra as a function of additional disks by varying D from 1 to 2, 4, 8, and 12. For each configuration, we analyzed the performance of Mitra as a function of the number of disks that constitute a cluster (i.e., d). In all experiments, the stride (k) equals to d. For example, with a 12 disk configuration (D=12), a cluster may consist of two disks (d=2). With this configuration, stride would also equal to two (k=2). Obviously, the choice of d and k has a significant impact on the obtained results. We analyze the performance of Mitra for those values of d and k that are reasonable(9). For example, with D=12, it would be unreasonable to configure Mitra with d=k=8 because it would force the bandwidth of four disks to sit idle as the database consists of a single media type. With d=k=8, the performance of Mitra with D=12 would be reduced to that with D=8. Figure 8a presents the number of simultaneous displays supported by Mitra as a function of D and d. In this figure, the number of disks available to Mitra is varied on the y-axis, the number of disks that constitute a cluster is varied on the x-axis, and the throughput of the system is reported on the z-axis.
(a) Number of simultaneous displays
(b) Percentage difference between theoretical expectations and obtained results from Mitra
Figure 8: Performance of Mitra as a function of D and d (k=d)
As the number of disks in the system (D) increases from 1 to 12 with d=k=1, the throughput of the system increases super linearly (the throughput of Mitra with D=12 is fourteen times higher than that with D=1). This is because the average transfer rate of each disk increases as a function of D. The explanation for this is as follows. In this experiment, the size of the database is fixed and the EVEREST file system organizes files on a disk starting with the outermost zone, i.e., fastest zone. The amount of data assigned to each disk shrinks as D increases. With D=1, the innermost zone of the disk contains data, while with D=12, only the three outermost zones contain data. The average transfer rate of the three outermost zones is higher than the average transfer rate of all 23 zones of a disk (see Figure 4).
In Figure 8b, for a given hardware platform (fixed D), the throughput of Mitra drops as d increases. For example with D=12, Mitra's throughput drops from 168 streams to 100 as d increases from 1 to 12. This is because the percentage of wasted disk bandwidth increases as d increases in value [GK95]. To observe this, note that both the maximum seek time and rotational latency are fixed. Moreover, they waste disk bandwidth. The percentage of wasted disk bandwidth is a function of these two values along with the amount of data read from each disk drive per time period. As d increases in value, the amount of data retrieved from each disk decreases because a block is declustered across a larger number of disks. This wastes a higher percentage of disk bandwidth, resulting in a lower throughput.
For each choice of D, we located the slowest participating zone of the disks that contains data. This zone is the same for all disks due to the round-robin assignment of blocks of each object to disks. We computed expected performance of Mitra as a function of this zone's transfer rate for each configuration (using the analytical models of [GKS95][GK95]). Next, we examined how closely Mitra approximates these theoretical expectations. Figure 8b presents the percentage difference between the measured results and theoretical expectations. Each value of this figure is computed based on: 1-(Measured)/(Theory). With D=1, the system approximates the theoretical expectation with 100% accuracy. With D > 1, Mitra's performance is anywhere from 10% to 35% lower than its theoretical expectations. Part of this is due to loss of network packets using UDP and their retransmission with HP-NOSE. However, there are other factors (e.g., SCSI-2 bus, software overhead, system bus arbitration, HP-UX scheduling of processes, etc.,) that might contribute to this difference. These delays are expected with a software based system (based on previous experimence with Gamma [DGS+90] and Omega [GCKL92]) because the system does not have complete control on the underlying hardware.
A limitation associated with values of d smaller than D is that the placement of data is constrained with staggered striping. This results in a higher average startup latency (see Figure 9a). In addition, it increases the amount of memory required at each PM even with the PM-driven scheduling paradigm (see Figure 9b). Consider each observation in turn. The average startup latency is higher because a display must wait until the cluster containing its first subobject has sufficient bandwidth to retrieve its referenced block. Similarly, each PM requires a larger amount of memory because the Scheduler cannot simply skip one time period on its behalf. Its next block resides on the cluster adjacent to the currently active cluster. Assuming the system consists of C clusters, a PM must cache enough data so that the Scheduler skips multiples of C time periods on behalf of this PM.
(a) Average startup latency 
(b) Maximum amount of memory required at a PM Figure 9: Startup latency and memory requirement of a PM with Mitra