of Service (QOS), and to manage system resources over ... changed to meet the resource restriction. ... processes a media data unit (MDU), such as a frame.
QOS Control of Continuous Media:
y
Architecture and System Support
Kiyokuni Kawachiya1 Masanobu Ogata2 Nobuhiko Nishio3 Hideyuki Tokuda3 1 IBM
Research, Tokyo Research Laboratory, 2 Power Mobile Systems, IBM Japan, Ltd. 3 Faculty of Environmental Information, Keio University
In an interactive multimedia environment that handles multiple sessions dynamically, a mechanism for controlling the Quality of Service (QOS) among sessions is very important. The QOSControl Server described in this paper is such a mechanism, developed on RT-Mach. This paper gives the results of several experiments with this server, and describes the extensions of RT-Mach needed for ecient QOS control. The thread-model extension makes it possible to create a thread suitable for processing continuous media, and the CPU-reservation mechanism gives more ecient QOS control. In accordance with these experiments, a new QOS-control model based on \QOS-Ticket" is proposed. In this model, QOS control is achieved through cooperation of the operating system, the QOS Manager, and each continuous-media session. The QOS-Ticket, which represents the resource reservation for each session, mediates these activities.
Abstract.
1 Introduction
The Keio-MMP (MultiMedia Platform) project has as its aim the development of a common software platform for distributed multimedia computing [1]. The project is sponsored by the Information-technology Promotion Agency, Japan (IPA), and is being carried out by Keio University and several companies, including IBM Japan, Ltd. (Tokyo Research Laboratory). One goal of our project is to incorporate the concept of Quality of Service (QOS), and to manage system resources over multiple continuous-media sessions on the basis of this concept. However, it is dicult for multimedia applications to manage their QOS appropriately by themselves without system support. We therefore selected RealTime Mach 3.0 (RT-Mach) as a basis for such system support. We are extending RT-Mach and constructing servers for multimedia processing on our extension [2, 3], as shown in Fig. 1. As a mechanism to control the QOS among multiple sessions dynamically, we adopted a QOS Manager-based scheme, and developed an experimental QOS-Control Server on RT-Mach [4]. This server controls the allocation of the CPU resource to multiple sessions according to the system load and the characteristics of the sessions. The rst part of the paper gives the results of several experiments with the QOS-Control Server, and describes the extensions of RT-Mach needed for ecient
Multimedia Applications Integrated Media Server (Conductor/Performer) RealTime Servers
OS Servers
Media Base
AAAAAAAAAAA AAAAAAAAAAA AAAAAAAAAAA Real-Time Microkernel (Extended Real-Time Mach)
Fig. 1: Multimedia platform in the Keio-MMP project QOS control. Next, in accordance with the results of the experiments, we propose a new QOS-control model based on \QOS-Ticket." We also discuss the system extensions necessary for implementing the QOS-Ticket model.
2 Models of QOS Control
The most notable characteristic of data for continuous media such as audio and video is the existence of constraints on the timing of the data processing. To handle such data appropriately, the system must observe the timing constraints, and must guarantee suf cient system resources (CPU, memory, disk, network, etc.) for the processing. Of course, the real system resources are nite, and consequently sucient resources
y This research is conducted under the Open Fundamental Software Technology Project of Information-technology Promotion Agency, Japan (IPA).
1
Frame Continuousmedia session
Frame-rate adjustment
...
Continuousmedia session 2. QOS adjustment
1. System load Time
High QOS
Operating System Frame-quality adjustment
(a) Self-stabilization scheme
Low QOS
1. QOS-factor registration/change
QOS Manager
Fig. 2: Example of QOS management: video processing
Continuousmedia session
3. QOS adjustment
: Continuousmedia session
may not be provided for a particular processing session. In such cases, the execution time is usually extended. But in continuous-media processing with timing constraints, the QOS should be changed to overcome the resource shortage [5]. For example, in video processing, the frame rate and/or the quality of each frame can be changed to meet the resource restriction. Figure 2 illustrates an example of this QOS management. The section in the upper-right represents high-QOS processing, and the section in lower-left represents low-QOS processing, which requires few resources. There may be a \static" resource-management policy according to which a continuous-media session is allowed to start only if there are sucient resources for the processing (admission control). However, in an interactive multimedia environment that handles multiple sessions dynamically, some mechanism for controlling QOS among sessions is preferred. Several models can be considered as candidates for such a mechanism [6]; one such model is the self-stabilization scheme shown in Fig. 3(a). Each continuous-media session observes the system load and adjusts its QOS by itself. This scheme is suitable for small-scale systems, because each session can control the QOS independently. However, in this scheme it is dicult for each session to cooperate with other sessions or to re ect priorities of sessions. In largescale systems, therefore, some coordinator that controls the QOS from session to session is needed. As such a mechanism, we have been considering another QOS-control scheme, shown in Fig. 3(b). In this scheme, the QOS is controlled through cooperation between the QOS Manager and each continuous-media session. Each session registers its \QOS factor" with the QOS Manager. A QOS factor is a list of attributes that
2. System load
Operating System
(b) QOS Manger-based scheme
Fig. 3: Models of QOS control describe the characteristics of the session. In accordance with the QOS factors and the system load, the QOS Manager centrally arbitrates the QOS of the sessions. We adopted the QOS Manager-based scheme for our QOS-control model. To implement such a scheme, systemlevel supports are indispensable [7]. In the next sections, we will consider these system supports on the basis of several experiments of QOS control over the CPU resource.
3 A QOS-Control Server on RT-Mach
As the basic software of our multimedia system, we chose RT-Mach, an operating system based on the Mach microkernel [8, 9] with several real-time extensions such as real-time threads, a real-time scheduler, real-time synchronization, and real-time inter-process communication (IPC) [10, 11, 12]. As shown in Fig. 4, continuousmedia processing programs can be written in RT-Mach by using the system's periodic real-time thread, which processes a media data unit (MDU), such as a frame of video data, on every invocation. In this paper, such threads will be called \CM-Threads." If the deadline for MDU processing (typically, at the next invocation time) is missed, RT-Mach can report the fact through a deadline port. 2
CM-Thread
main() { : /* Create a periodic RT-Thread */ rt_thread_attribute_init( ..., period, work_entry, ...); rt_thread_create(...); : }
Table 1: QOS factors of dummy CM-Threads Exec.term(sec) No.
work_entry() /* invoked periodically */ { /* Process a frame */ }
QOS decrease
Fig. 4: Continuous-media processing in RT-Mach
Thread list 1 2 3
Thread-death CM-Threads notification 1
Main thread
QOS-factor registration 2
Monitoring thread
DL-monitor thread DL misses
1
0
2
0
3
10
4
20
! ! ! ! !
end
Workload
Period(msec)
Pri-
min { max
ority
60
10
50 (Fixed)
60
50
30 { 100
10
40
50
30 {
15
50
50
30 {
1 1
100
30
must be reduced, the server selects the CM-Thread in which the current value of (period 2 priority) is the smallest, and extends its period. Conversely, when the system load becomes light and the QOS can be increased, the server shortens the period of the CM-Thread in which the value of (period 2 priority) is the largest. To judge the system load, the server uses the deadlinemiss count of CM-Threads. As shown in Fig. 5, two threads are used for this purpose. The DL-monitor thread monitors the CM-Threads' deadline ports, which are passed to the server when the QOS factors are registered. When the DL-monitor thread is noti ed of a deadline miss, it judges that the system is overloaded and reduces the QOS of some CM-Thread. The monitoring thread is a periodic real-time thread in the server. When no deadline miss occurs in a period, the thread infers that the system load is light, and increases a QOS. Experiment 1 was carried out to determine how well the server controls the QOS of multiple sessions. The four dummy CM-Threads shown in Table 1 were used in this experiment. These dummy threads were realtime threads that were periodically invoked to execute a speci c number of dummy loops according to their workload values. Dummy thread 1 represents a session in which the work is light but the QOS cannot be changed, such as some types of audio processing session. Dummy thread 2 allows a change in the QOS, but in the worst case requests a 100 msec period. Dummy threads 3 and 4 are sessions started during thread 2, and their priorities are higher than that of thread 2. The experiment was done on an IBM ThinkPad 755C (9545-L, IntelDX4-75MHz) with RT-Mach MK83g using the rate monotonic scheduling policy. Figure 6 shows the period (QOS) of each dummy thread speci ed by the server.1 In the rst 10 seconds, the system load was light and the highest QOS (minimum period) was speci ed for threads 1 and 2. But after threads 3 and 4 were started, the system became overloaded, and the period of each thread was extended according to its QOS factor. When threads 3 and 4 were
Time
QOS-Control Server
start
3
QOS decrease (extend a period) QOS increase (shorten a period)
Fig. 5: Experimental QOS-Control Server Using these features, we developed an experimental server named QOS-Control Server. This server controls the QOS of multiple continuous-media sessions by changing the period attribute of the CM-Threads, as shown in the lower part of Fig. 4. This corresponds to a change between left and right in Fig. 2. Figure 5 shows the structure of the server. Each CM-Thread registers its QOS factor with the server via Mach IPC at the time it is started. In the experimental server, the range of periods that a CM-Thread can accept and the priority of the session (a high value means high priority) are used as the attributes of a QOS factor. In accordance with the QOS factors, the server changes the periods of the CM-Threads. When the system becomes overloaded and the QOS of some CM-Thread
1 In the experiments described in this paper, the period was used as a QOS value. Therefore, in the graph, the lower value represents the better QOS.
3
qosmgr -m0 qosmgr_test -m0 qosmgr -m0 qosmgr_test -m0
High QOS Low QOS
180
Transient overload
CM-Thread 1 CM-Thread 2 CM-Thread 3 CM-Thread 4
160 140
Invocation timing
(a) CATCH UP
120
1
2
1
2
3
4 3
5
6
4
7
8
5
9 6
10 7
8
11
Time
9
(b) SKIP ALL
100
1
2
1
2
3
4
5
6
7
8
9
10
11
9
10
11
9
10
11
10
11
80 3
60
Th.2
20
Th.3
10
20
30 Time (sec)
40
50
1
2
1
2
3
4 3
5
ended, the QOS of thread 2 was increased again. For thread 1, a xed QOS (a 50 msec period) was speci ed for the whole experiment. In this experiment, QOS control was partially achieved, but there were two major problems: rst, the period speci cation for each thread jumped up before settling, as shown in the section between 20 sec and 30 sec; and second, the QOS value vibrated even after the speci cation had settled.
4 OS Support for Ecient QOS Control
The main reason for the problems in experiment 1 was that the system-level support is insucient for ecient QOS control. That is, The real-time thread model is not suited to the QOScontrol scheme. Cooperation between the QOS-Control Server and the OS scheduler is weak. To achieve more ecient QOS control, we made several extensions to RT-Mach and the QOS-Control Server. This section gives the results of additional experiments based on these extensions. Extending the Real-Time Thread Model
The biggest problem in experiment 1 was the jump in the period. We investigated the behavior of the CMThreads, and found that the problem was caused by the \CATCH UP" semantic of the periodic thread. Figure 7 shows the invocation timing and the actual execution of a periodic real-time thread in RT-Mach.2 The behavior of the CATCH UP mode, which is an original mode of RT-Mach, is shown in Fig. 7(a). In this mode,
1
2
1
2
4 reset 4 4'
(d) RESET
60
Fig. 6: Result of QOS control (Exp. 1)
4.1
skip 8
6
7
8
Th.4
0 0
7
skip 6
(c) SKIP ALL-1
Th.1
40
5
skip 4
3 3
skip 5
6
reset 5' 5'' 4'
7 9 skip 8 reset 6'' 6'''
5''
reset 7''' 7'''' 6'''
7''''
AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA AAA
8'''' 8''''
9''''
Fig. 7: Behavior of periodic threads during overload
the invocation timing is decided in advance and is not changed even if the system becomes overloaded. Consequently, if a processing unit is not nished before the next invocation time, the \debt" is transferred to subsequent invocations. The debt must be repaid before the system returns to a stable state. As a result, even after an overload, the deadlines continue to be missed until the thread \catches up" with its original timing.3 This caused the jump in experiment 1. This CATCH UP semantic is important in hard realtime systems that need exact invocation timing, but may not always be suitable for soft real-time processing such as continuous-media processing. In continuousmedia processing with QOS control, the settlement of transient overload is more important than the exact invocation timing. Therefore, several new semantics have been added to RT-Mach, including SKIP ALL and SKIP ALL01 modes [13]. In these modes, the invocation timing is not changed, but some processing units are \skipped" when the system becomes overloaded. In the SKIP ALL mode, if a processing unit is not nished by the time of the next invocation, all processing units for the slots intruded into are skipped (Fig. 7(b)). In the SKIP ALL01 mode, the last unit, instead of being skipped, is executed in the remainder of the slot (Fig. 7(c)). In these SKIP ALL-type semantics, the invocation timing is preserved, but in continuous-media processing, 3 For example, in Fig. 7(a), the seventh processing unit is executed in the ninth invocation slot, so a deadline miss is reported.
2 The gray ovals in Fig.
7 indicate that the thread is in \runnable" state, though not necessarily running.
4
qosmgr -m0 qosmgr_test -m1 qosmgr -m0 qosmgr_test -m1
qosmgr -m0 qosmgr_test -m1 qosmgr -m0 qosmgr_test -m1 ---> Low QOS
180 CM-Thread 1 CM-Thread 2 CM-Thread 3 CM-Thread 4
160 140
Period (ms)
120 100 80 60
High QOS
