Design and Implementation of the Stony Brook Video Server

Abstract

SUMMARYThe system architecture of the Stony Brook Video Server (SBVS), which guarantees end-to-end real-time video playback in a client-server setting, is presented. SBVS employs a real-time network access protocol, RETHER, to use existing Ethernet hardware as the underlying communications media. The video server tightly integrates the bandwidth guarantee mechanisms for network transport and disk I/O. SBVS's stream-by-stream disk scheduling scheme optimizes the effective disk bandwidth without incurring significant scheduling overhead. To demonstrate the feasibility of the proposed architecture, we have implemented a prototype called SBVS-1, which can support five concurrent MPEG-1 video streams on an Intel 486DX2/EISA PC. To our knowledge, this system is the first video server that provides an end-to-end performance guarantee from the server's disks to the each user's display over standard Ethernet. This paper describes the implementation details of integrating network and I/O bandwidth guarantee mechanisms, and the performance measurements that drive and/or validate our design decisions.

Efficient memory management in video on demand servers

“…in Refs. [1,3,6,7,11,15,17,19,21,22,30]). The most popular per-stream buffering implementation, Double Buffering, is based on the co-operation of two buffers of identical size allocated to each client.…”

Concurrent push-A scheduling algorithm for push-based parallel video servers

“…The server-push model is common among studies on singleserver VoD systems [1]- [4], [8]. This model allows one to design periodic schedulers [8] to optimize disk and network utilization.…”

“…The retrieved video block is then passed to a network buffer for transmission in the next round. 1 Therefore, if the disk service round is shorter than one transmission round, a video block will always be ready for transmission. We analyze the performance of the system under this scheduling algorithm in the next section.…”

“…From Section III-B, setting , then the playback time for video block group , denoted by , is bounded by (11) To guarantee video playback continuity, we must ensure that a video block group arrives before the playback deadline. In the worst case, the latest filling time must be smaller than the earliest playback time, i.e., (12) Now, for the left-hand side, noting that [see (1) and (4)], we then have (13) Using the upper bound for from Theorem 1, we obtain (14) Similarly, the right-hand side is (15) Merging (14) and (15), we then have (16) Rearranging, we can then obtain (17) Knowing the number of groups required, we can then obtain from (18)…”

“…Specifically, the analysis in Section III reveals that the main reason for the increase in client buffer requirement with the number of servers stems from the increase in the average filling time in (1). This suggests that we can reduce the buffer requirement by using smaller striping size .…”