Continuous Media Storage and Retrieval - Scalable Continuous Media Streaming Systems - page 51

with capacity of k concurrent streams we can at most divide them into g k groups under

GSS. However, in this case the disk will serve the streams one by one in a round-robin manner,
effectively reducing to FCFS!
Knowing that FCFS has poor disk throughput, it raises the first trade-off in usingmore groups
under GSS. Specifically, with k requests divided into g groups, each micro-round will retrieve
only k / g data blocks. Since we are using worst-case analysis to dimension disk capacity, we
will assume that the k / g data blocks are evenly spaced across the full span of the disk surface.
Thus, with more groups, fewer requests are served in each micro-round, which in turn increases
the worst-case per-request seek distance. Obviously this added overhead will result in longer
service round length and thus reduces disk throughput.
The second trade-off is more subtle and only occurs under heavy system load. Specifically, if
a new streamarrives to find the next micro-round already fully occupied, then it will have towait
for a group with available capacity to join. Note that this scenario will not occur if the number
of active streams in service is smaller than k / g , as none of the groups will be fully occupied. As
more and more streams join the system, more and more groups will be fully occupied. In the
worst case a new stream could arrive in the middle of the only group with available capacity,
and thus will need to wait until that particular group cycles back again in the next macro-round.
In this worst-case scenario the admission delay will become ( g

=

t max g ).

Nevertheless, the beauty of the GSS scheduler is that we can control the trade-off between
throughput and buffer requirement/admission delay by dividing the streams into different
number of groups. In fact, theGSS scheduler subsumes as special cases both the FCFS scheduler
(when g

+ 1) ·

round ( k

/

1). The same principle will also find
applications in multi-disk (Section 3.5.3) and multi-server streaming systems (Part II of the
topic).

= k ) and the CSCAN scheduler (when g =

3.5 Multi-Disk Storage And Retrieval
So far, we have only considered media storage and retrieval in a single hard disk. In practice,
the capacity of a single disk may not be sufficient to serve a large number of concurrent users.
While disk storage capacity is advancing rapidly, improvements in disk throughput are far
slower due to mechanical limits like spindle speed, disk seek, etc. Therefore in most, if not all,
media servers, an array of disks will be needed to provide sufficient streaming capacity. The
challenge then is how to efficiently store and retrieve media data from multiple disks.

3.5.1 Partition and Replication
First, if the disks are operated independently, i.e., each disk is accessed independently from
other disks using, say, a separate logical disk drive or filesystem, then we can simply distribute
the media objects such as movie files to the disks according to certain placement policy. For
example, we may place media object 1 in disk 1, media object 2 in disk 2, and so on. When a
user requests the streaming of media object 1, then the server will simply retrieve the media
data blocks from disk 1 for transmission to the user. Each disk in this case is independent and
thus the same disk schedulers discussed earlier in Sections 3.2 to 3.4 can be applied directly
without modification.