Project in Advanced Programming B (236512)
Winter 2009-2010
Assignment 2
The code + documentation need to be submitted (via e-mail) by Friday 4/12/09.
The goal of the project is to evaluate the potential benefit from allowing some of the clients to
get partial type-B transmissions. In this assignment you will simulate a system in which all
clients get only type-A transmission. In the next assignment you will simulate a (more
complex) system in which partial type-B transmission is possible. In the final stage you will
compare the performance of the two systems.
In Assignment 1 you simulated the static allocation phase of the second system. This part will
be used in Assignment 3. The following is a description of a system with exactly the same set
of resources and the same library of movies, but without the support of type-B transmissions.
The storage allocation uses the same method (and should be very easy to implement, given the
code you already have for the more elaborated system: set α=0).
Recall that our Media-on-Demand system consists of 50 disks (servers) organized in four
clusters. One of these clusters is the root. The other 3 are called pop-clusters. The root consists
of 20 servers, and each of the 3 pops consists of 10 servers. The storage capacity of each
server is 660,000Mb (approx 2/3 Terabytes). The system has a library of M=12500 movies.
The system supports transmission in high QoS (type-A transmission) only. Each movie file is
stored in a format requiring 880Mb.
1. Implement the static allocation of file copies to the servers. First, as in Assignment 1,
determine how many copies will be stored of each movie (this time it must hold that Σi Fi =
50*660,000/880=37500). Next, use the same round robin algorithm to determine which
movies are stored on which server (again, at least one copy of each movie must be stored
on the root cluster).
2. In this part you will simulate the complete MoD system using an event-driven mechanism.
The initialization of the system is the static allocation. Assume that the streaming (load)
capacity of each server is L= 480, that is, each server can transmit broadcasts to 480
different clients simultaneously (as explained in the sequel, this refers to local clients).
The system services clients from 3 geographical regions: R1, R2, R3. Each of the three popclusters is located in one of these regions (and is denoted the local cluster of the region).
The dynamic phase starts right after the static allocation. It should be implemented using an
event-driven mechanism, starting from time t=0. There are two types of events to handle:
(i) New clients are arriving. (ii) Clients who complete watching their movie are leaving.
Arrival of a new client: Whenever a new client arrives, use the 80-20 distribution function to
determine the requested movie. Also, determine (with probability 1/3 for each region) the
geographical location of the client. If some server in the local cluster of the client holds the
movie and is not fully loaded then the client is serviced right away from the least loaded server
in the cluster, among those that hold a copy of the movie; else, the request is transferred to the
root cluster, and the same check is performed. If the root cluster cannot service the client, the
request is transferred to the two other pop clusters. If no pop cluster can service the client then
the client is rejected. A client watches the movie for 60 minutes.
Remote Service: As mentioned above, a client from one region can be serviced by a remote pop
cluster, or by the root – if the requested movie is not available from his local cluster. However,
such a remote service is expensive. A remote transmission requires 1+ρ bandwidth units (while
transmission to a local client requires one unit of bandwidth). The parameter ρ denotes the
additional bandwidth cost for remote service. For example, if ρ=0.25 then a server can reach its
complete load capacity by transmitting to 355 local clients plus 100 remote clients, since
355*1+100*1.25 = 480= L.
Client Departure: If a client is serviced then after 60 minutes the load on the corresponding
server is reduced by one.
General Guidelines:
• Run a simulation of 24 hours (= 1440 minutes) of the system, with no client-arrival events
during the last 60 minutes. (Note: This is the simulated time; do not run your program for 24
hours.)
• The output of your program should include a report of all the events performed throughout
the execution of your program. For example (this sequence of events is not possible, this is just
to give you an idea of what we expect to see as output):
Time = 1, Client 1 from R1 arrives, requested file: 1402, serviced from disk: 5 (in C1)
Time = 16, Client 2 from R3 arrives, requested file: 2453, serviced from disk: 35 (in ROOT)
Time = 18, Client 3 from R1 arrives, requested file: 5336, rejected.
Time = 19, Client 4 from R3 arrives, requested file: 18904, serviced from disk: 34 (in ROOT).
Time = 61, Client 1 leaves
•
In your simulation, set ρ=0.2 (but keep it as a parameter).
•
The length of the time interval between two successive arrivals of client requests is a
random variable with exponential distribution function. Find the parameter of this function
that keeps your system busy without rejecting too many clients (<1%). For implementing
the exponential distribution, we recommend that you read Section 2 in the Lecture notes on
Simulation, posted in the lab Web site.