QOS Control of Continuous Media: Architecture and System Supporty

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