Implementation Techniques for Multimedia Storage Servers and Networking (Spring 1999)

Tzi-cker Chiueh

Group members

Table of Contents

Project Goal

• Clients make request through BSD-style sockets.
• Each request is of the form "get file_name file_offset required rate".
• The server implements a cyclic scheduling.

Introduction

Our server consists of several parts, such as a disk storage subsystem and a control unit, which is responsible for the admission control and the scheduling of the request.  The admission control module decides if the server can satisfy a new request for the entire connection.  Cyclic scheduling means that within one cycle the required media blocks of all streams are retrieved from disk and sent to the clients.

Constraints of a user-level real-time network storage server:

• We can not guarantee exact retrieval times from the disk subsystem, because we are not able to influence data placement on disk, seek times, disk scheduling, etc.
• A non real time operating system (like Linux or Windows NT) can not guarantee an accurate runtime for a user level program. This is primarily due to interrupt handling and process scheduling.
• A regular Ethernet uses CSMA/CD for its arbitration process. This basically means that we can only offer  a best effort strategy instead of a QoS based approach. This is a limitation for the usage of our network storage server as far as end to end delivery guarantees are concerned. On the other hand most of the computer user today do not have a QoS network infrastructure.

Design Decisions

2. Admission Control
Our admission control is based on statistical averaging. To be able to decide whether to allow a new request to join or not is based on measured time consumtions of acutal fullfilled requests of past cycles.  The basic assumption behind this averaging is that we use historic calculated requirements to predict the future requirements.

To be more formallly, the following equation must be satisfied:

O.. additional overhead

P.. maximal time bound for one I/O cycle
 
 

Figure 1. Ideal cycle.

If all requests are satisfied within the current cycle and time is left, there are two possibilities to deal with this problem: Either the server waits in a loop (busy waiting), which is CPU intensive, or it sleeps until the end of the cycle. The operating system is responsible for waking the server, which cannot be that exact. As a consequence, the process might sleep longer as required [Figure 2] and therefore the next cycle-time is shortened by the time it slept too long[Figure 3].

Figure 2. Process sleeps too long.

Figure 3. Thus, next cycle is shorter.
 
 

Implementation Details

Used data structures:

typedef struct mm_stats {
  float  avg_bytes_per_usec; // average bytes per usec over the server's life time
  long   sum_usecs;         // sum of all usecs used for clients in this I/O cycle
  long   avg_sum_usecs;     // average sum of usecs used for clients over the server's life time
  long   sum_bytes;         // sum of all bytes sent in this I/O cycle
  int    num_clients;       // number of concurrent clients
  long   remaining_time;    // time left in actual I/O cycle
  long   adjust;            // time server slept too long
  long   avg_adjust;        // average of adjusts
  long   algo_time;         // time used for general code parts
  long   cycles;            // number of cycles
  long   working_time;      // time  spent on serving all clients in this cycle
  long   sum_working_time;  // sum of all working times spent over the server's life time
} mm_stats;
Listing 2.  Data structure for statistics.
 
 

Main server layout:

• Server runs in an infinite loop waiting for incoming requests.
• The client transmits a request by a "hello" packet using UDP/IP.

The request consists of a number of parameters:
    - The requested file
    - The file offset
    - The required rate (bytes per second)
This incoming request is added to a doubly linked list [listing 1] if the admission control module accepts the request..
• After new requests are added to the list, the server processes the list elements and sends the media blocks at the wanted rate of each stream, cycle per cycle.
• When the last block of the required file has been sent, the list entry of this client is dequeued
• When all clients are done, the remaining time is slept, to get one second per cycle
• then, some statistics (eg. the adjust value) are gained

Sources:

Performance Analysis

Test Environment

Operating system:

Hardware:

Clients:

Caveats:

Test Results

Figure 4. variable client requests and increasing number of distinct files

Figure 5 shows fixed client requests (45 clients)  and increasing distinct files.
The increasing number of distinct files leads to an increase of microsecs spent on each client to fulfill the wanted rate.

Figure 5. fixed client requests (45 clients)  and increasing number of distinct files