Local time: Friday, 05-Dec-2008 12:01:04 EST
Last update: at /special/conference/apwww95 , Friday, 21-May-2004 09:46:45 EST
Architecture of a Home Area Multimedia System
Alberto Nava and Bob Kummerfeld
Basser Department of Computer Science,
Madsen Building, F09, Sydney Uni., 2006
A 2 hour MPEG movie at 1.5Mbit/s requires 1.4Gbytes of storage space, while
broadcast quality, at 6.0bit/s, requires 5.4Gbytes[Kova94]. This is considerably more storage
than most home computers have today, however we predict that storage devices of at
least 10Gbytes will be available for under $500 by the year 2000 (see Figure 1).
Figure 1: Disk cost evolution
This graphic was composed using data from the last decade of BYTE magazines. If inflation
had been taken into account the decrease in cost per byte would be even greater.
Although the current generation of workstations do not decode MPEG at its
required rate[Pat93], their sustained 50% per year performance increase will permit the
next generation of workstations to decode full-size MPEG video and its associated
audio in real-time. Fortunately, the adoption of MPEG by the industry has allowed
the development of VLSI chips which decode MPEG streams at 30 frames per second,
providing a ready-to-use cost/effective solution.
The success of a home area multimedia system depends on our ability to construct
a system which provides high quality video and audio at a reasonable cost. For this
reason, we rejected any approach that implies sophisticated and expensive hardware,
for example large NV-RAM (non-volatile RAM) or RAID[Patt88]. NV-RAM has been used
as a intelligent way to postpone meta-data writes[Wen92].
Figure 2: Home Area Multimedia System Architecture
These components are connected using point-to-point links or sharing a bus.
The closet-box has two main elements: a communication server, which receives
programs from the multimedia providers using a non-real time delivery protocol, and
a multimedia file server that stores those programs for later display.
Our design goal is that the server must serve up to three simultaneous real-time
multimedia streams being presented to home terminals.
The terminals are connected to the closet box using either point-to-point links,
such as twisted pair Ethernet to dedicated ports, or using contention-bus technology.
The server to terminal delivery protocol assumes
Figure 3: Media File Server's Disk Layout
Figure 3 shows the disk-layout of mfs, our user-level file server. The first block
contains the "super-block", which stores administrative information about the file
system. After that we have a group of bitmap blocks representing space allocation
information. Later on, there is the root directory block, which contains most of the
file descriptors, and finally there are data blocks.
A media file server has to accommodate real-time operations together with meta-data operations. NVRAM is the standard way to postpone meta-data writes, while
caching has been used to reduce meta-data reads. We prefetch all the required meta-data before start to play a file, and minimise meta-data updates to eliminated its
overhead. This is a lossy updating method, because some common statistics are
not implemented or are not as accurate as they could be. For example, we do not
maintained an access time per file, and the modification time is the time of the close
after the file has been modified.
The file server operates as a two-state multi-line pipeline. Each open file contains
two memory buffers, one of them being transmitted to the network, and the other
one being read from disk. Jittering and delays are avoided as the playback time for
a single block is bigger that the retrieval time of n blocks, where n is the number of
streams being served[Ven91].
We measured the maximum bandwidth for different block sizes, and compared
those result with kfs, the original Plan 9 user level file system. Table 2 shows mfs
and kfs maximum bandwidths versus block size, as well as the per-stream bandwidth
obtained with two and three concurrent streams.
From those experiments we conclude that: mfs provides 1.7 times more bandwidth
than kfs, and that it distributes bandwidth between its clients 3.7 times more
effectively than kfs. Moreover, we could play 3 VHS or 2 broadcast quality videos
with it. The above results are conservative because we used a user-level file server
for our experiments, in which we did more than one read operation per block, had
some extra copies of data due to MMU-DMA interferences and could not control disk
scheduling.
We also analysed the amount of RAM memory required for each configuration.
Table 3 shows those values for the above configuration. In general we need 3 blocks
per file plus 3 meta-data blocks: the super-block, the bitmap block and the root
block. Using a flat-file system we reduce the number of blocks per file to 2.
Since any of the above configurations can serve the same number of streams, the
most cost/effective solution is the 64K-block configuration.
To understand why a Intel based plan 9 terminal running at 90MHz does not
decode and display MPEG files at real-time (25 frames per seconds), more detailed
tests were conducted. In the first test we measure how many 320x240-uncompressed
frames our machine could display per second. We measured 15 frames per second
using the 81/2window system, and 40 frames per second without it, a 2.6 increase in
frames per second without the window system.
The second test determined how many frames per second could be decoded without
displaying them, suppressing dithering and window system overhead. The result was
that we could play a 320x240 MPEG file at 8 frames per second.
In conclusion, our machine could not decode more that 8 320x240-frames per
second, which was reduced to 6 due to dithering and window system overhead. To
obtained full-motion MPEG decoding in plan 9 we plan to use an MPEG decoding
card and bypass the window system. Fortunately, plan 9 graphics applications can
run without the window system[Pike91] giving a performance increase.
beto@plan9.cs.su.oz.au,bob@cs.usyd.edu.au,[Fede94] is a service that
the telecommunication service providers see as the most important and
development is concentrated in this area. This service requires
considerable bandwidth and a consistent Quality-of-Service during each
session, consequently the network must be capable of this high
performance even when the majority of users are viewing different
programs. Unfortunately, there will be many periods each day when the
network is lightly loaded and the available bandwidth not used.
In [Kay94] we propose a service we call "video-on-order" to complement video-on-demand. Briefly, this involves treating multimedia material such as movies or radio
programmes as messages and pre-emptively caching them at a home terminal in
periods of low network utilisation. The decision of what to cache is based on a "user
model" or set of preferences for the user.
In order to cache and subsequently present multimedia material in the home a
powerful system is required. It must have a large amount of mass storage and the
ability to present several simultaneous multimedia streams via a home network to several presentation devices such as television sets. This paper describes the architecture
of such a system.
Goals and central ideas
The goals of the home area multimedia system are:
The most difficult requirements to satisfy involve the storage and replay of audio
and video. Other services will require less performance and capacity. In this part of
our project we are concentrating on multimedia materials in MPEG[MPEG91] or
JPEG[JPEG92]
formats. Furthermore, we are building the prototype from available hardware.
The use of MPEG for video and audio, reduces the network and disk bandwidth
required for real-time retrieval, as well as the storage space required. Table 1 shows
MPEG's network and disk requirements for different type of media. Those values are
well within the current state of the art in network technology and disk transfer rates.
Moreover, several concurrent streams could be supported using inexpensive local area
network and disk technology.
MPEG Media bit/s bytes/h CD Audio 128K 60M HS quality video 1.5M 700M Broadcast quality video 4-6M 1.8-2.8G Architecture
Figure 2 presents the system we propose. The current generation of cable television
systems uses a "set-top-box" as the interface between the network and the user terminals (television sets). The main processing and mass storage component of our
system is currently too large for a "set-top" and probably needs to be more centrally
located in the home. Therefore we think of it as a "closet-box" stored in a convenient
cupboard.
The other parts of the system are terminals that display multimedia materials.
These may be simple devices similar to the television set of today but could also be
more like a computer terminal.
These assumptions are reasonable given point to point links, dedicated controllers
for each link and at least 10Mbps raw bandwidth.
The system software is built on the Plan 9 distributed computing environment[Pike90]
from AT&T Bell Laboratories.
Plan 9 is assembled from separated machines running as cpu servers, file server and
terminals. CPU servers are high performance machines used for intensive computation
and compilation, file servers implement the storage system, and terminals are used
to run the windows system and users applications.
In our multimedia system, the file server is a repository of multimedia materials
as well as normal plan 9 files. The cpu server is used to connect to the multimedia
providers, using a non-real time message based protocol, and terminals are used as
hyper-media browsers and viewers.
Media file system design
Most continuous media servers[Wen92][Lou94][Ven91] are special purpose machines or cluster of
machines[Lou94][Free95] which only serve continuous media data. However, we need to serve
normal Plan 9 files as well as continuous media data. The server implements two file
systems: the root file system, which contains plan 9 files, and /media file system
which contains media files. Different disk layout, cache mechanisms and disk scheduling will be used on /media, in order to provided the necessary Quality of Service.
Intelligent cpu scheduling and network management are also needed in order to serve
both types of files without introducing jittering or delays to the media streams.
To built an affordable system we did not considered standard video-on-demand
technologies, such as NV-RAM, RAID[Patt88] machine clustering[Lou94][Free95]. Current video-on-demand systems use very large, powerful systems to serve as many as 500 house-holds. Our desig
n was driven by the fact that we have to serve a small number of
streams, which will be accessed sequentially. Moreover, we believe that concurrent
access to a particular stream will not be common in a home area network, and when
it happens, it will be spaced enough in time to be considered as different streams.
For the reasons given below, we will not use caching in our file server. Caching has
been used to compensated the speed difference between main memory and the storage system. However, due to the sequential and no-shared access pattern it is not of
benefit in our system.
To compensated for storage access delays, principal seek time and network delay,
we will use client buffering of data and aggressive server prefetching from the storage
level. When a client starts to play a video or audio file, it downloads data from the
server until it's buffer space is filled. After that, it requests data from the server
each time space becomes available. Simultaneously the media server prefetches the
next block of data from the disk, similar to the well-known read-ahead strategy. We
plan to experiment with block sizes between 65K and 512K. When choosing the block
size, there is a compromised between minimising seek overheads and service time per
block[Lou94].
A user-level media server
To evaluate the effect of large blocks and prefetching we designed and implemented
a user-level media file server, which uses large blocks, disk prefetching, linked-list
allocation and lazy statistical maintenance.
A key feature of the Plan 9 operating system is the use of user level file servers
that service requests for data from some point in the name space.
fs/bsize Max. Band 2 users 3 users kfs/8K 5.6 1.2 0.6 mfs/64K 9.7 4.5 2.8 mfs/128K 9.8 4.7 2.9 mfs/256K 9.8 4.7 2.9 mfs/512K 9.8 4.7 2.9
fs/bsize RAM RAM 3 VHS 2 Broadcast per stream for meta-data Quality Quality mfs/64K 192K 192K 768K (256Kps) 576 (288Kps) mfs/128K 384K 384K 1536K (512Kps) 1152 (576Kps) mfs/256K 768K 768K 3072K (1024Kps) 2304 (1152Kps) mfs/512K 1536 1536 6144K (2048Kps) 4608 (2304Kps) MPEG performance in Plan 9
The software based MPEG decoder[Eckart] was ported to plan 9, and its performance
evaluated with and without the window system, 81/2[Pike91]. Table 4 shows the result of
these tests.
frame size fps with 81/2 fps without 81/2 frame size 16 16 frame size 6 7 Work in progress and further work
The user level implementation of mfs is the first step toward the implementation
of a home area multimedia system. Currently, we are working on the design and
implementation of:
Conclusion
The architecture of a home area multimedia system, which provides real-time delivery
of multimedia programs, was presented, as well as the design and implementation of
its multimedia file server.
Using large blocks and prefetching, a user-level implementation of our media server
provides 1.7 more bandwidth than the original plan 9 user-level file server (kfs), and
shares its available bandwidth four times more effectively than kfs. This server
could play 3 MPEG encoded VHS quality streams or 2 broadcast quality streams
concurrently, using 256 or 288 Kilo-bytes of memory per stream.
An experimental home area system is currently being implemented using the plan
9 distributed system.
References
[Return to Table of Contents]
COPYRIGHT © 1995 by AUUG95 and APWWW95 Charles Sturt University. ALL
RIGHTS RESERVED.
