Peer-to-Peer Netw. Appl.
DOI 10.1007/s12083-013-0219-1
A real-time responsiveness measurement method
of linux-based mobile systems for P2P cloud systems
YungJoon Jung Donghyouk Lim Yong Bon Koo
Eun-Ser Lee Hoon Choi
Received: 1 February 2013 / Accepted: 7 June 2013
Springer Science+Business Media New York 2013
Abstract Linux-based mobile computing systems such
as robots, electronic control devices, and smart-phone
are the most important types of P2P cloud systems in
recent days. To improve the overall performance of net-
worked systems, each mobile computing system requires
real-time characteristics. For this reason, mobile comput-
ing system developers want to know how well real-time
responsiveness is supported; several real-time measure-
ment tools have been proposed. However, those previ-
ous tools have their own measurement schemes and we
think that the results from those models do not show
how responsive those systems are. In this paper, we
propose ELRM, a new real-time measurement method
that has clear measurement interval definitions and an
accurate measurement method for real-time responsive-
ness. We evaluate ELRM on various mobile comput-
Y. Jung D. Lim Y. B. Koo
ETRI, Daejeon, Korea
Y. Jung
e-mail: jjing@etri.re.kr
D. Lim
e-mail: befree@etri.re.kr
Y. B. Koo
e-mail: ybkoo@etri.re.kr
E.-S. Lee
Andong University, Andong, Korea
e-mail: eslee@andong.ac.kr
H. Choi ()
Chung-nam National University, Daejeon, Korea
e-mail: hc@cnu.ac.kr
ing systems and compare it with other existing mod-
els. As a result, our method can obtain more accu-
rate and intuitive real-time responsiveness measurement
results.
Keywords Real-Time Responsiveness Measurement
Measurement interval Preemption latency
1 Introduction
Nowadays, the market for mobile computing systems such
as smart-phones, portable media players and portable game
players is getting bigger. These mobile computing systems
have become the most important members of P2P cloud
systems. We can see two significant trends in these mobile
computing systems. First, RTOS-based embedded systems
are being replaced by Linux-based mobile computing sys-
tems due to cost efficiency. Second, the need for real-time
responsiveness is increasing since many devices have to pro-
vide services in limited time. In particular, mobile systems
should be in connected state and data transmission must
be fast. To improve the latency of data transmission, the
real-time responsiveness of mobile systems must be also
improved.
However, the Linux operating system was originally
designed for general purposes. It does not support the real-
time responsiveness needed to fulfill the requirements of
mobile computing devices. Therefore, it is important to
improve real-time responsiveness features of Linux-based
mobile computing systems. To compensate for the lack of
real-time features in Linux-based mobile computing sys-
tems, many studies have been conducted in the Linux
developer community. We can divide these related studies

into two groups according to their implementations. One
approach, like RTLinux [1] in Fig. 1, is adding a real-time
kernel below Linux. In this method, Linux runs as a server
process to provide timeliness to real-time tasks. This has
been supported since Linux kernel 2.4 and has been applied
to avionic systems, military systems, industrial robots and
medical instruments.
Another approach is to improve the real-time respon-
siveness of the Linux kernel itself. The performance of
the Linux kernel was significantly improved. As the Linux
kernel advances, various features become focused on the
responsiveness. Representative features are as follows: O(1)
Scheduler [2, 3], Voluntary Kernel Preemption [4], Pre-
emptible Kernel [57], Ingo Molnars real-time preemp-
tion patch [8], and Improved Prioritized Interrupt Thread
Scheduling. The responsiveness of Linux-based mobile sys-
tems was significantly improved by studies focused on
real-time features and measurement [9, 10]. However, the
common way of the responsiveness measurement does not
still exist. The researchers developed their own measure-
ment method to evaluate results. Such situation makes
things hard to compare their studies.
In this sense, proposing a unified measurement method is
essential. This can be a common criterion of real-time sys-
tem evaluation and the responsiveness of real-time systems
can be compared in an easier way. We propose a common
method, ELRM (Embedded Linux Real-time responsive-
ness Measurement method) that can be utilized when we
measure real-time responsiveness; our method is also clear
and intuitive.
The remainder of this paper is organized as follows. In
Section 2, we present related works and their pros and cons.
The requirements, mechanism, and constraints of real-time
responsiveness measurement are described in Section 3. We
explain our measurement method and implementations on
various mobile computing systems. The results from our
measurement method and comparison of it with other meth-
ods are presented in Section 4. Finally, Section 5 presents
our conclusion and future work.
Fig. 1 Block diagram of RTLinux
Peer-to-Peer Netw. Appl.
2 Related work
The real-time characteristic is one of the most important
characteristics that Linux-based mobile systems can have.
Therefore, many studies on evaluating real-time responsive-
ness have been conducted. We will introduce some existing
testing tools and talk about the pros and cons of each testing
tool.
2.1 Cyclictest
Cyclictest [11] is a tool that was developed by the Thomas
Gleixner, who is one of the maintainers of Ingo Molnars
real-time preempt patch. It is one of the most popular,
widely used tools in the Linux developer community.
The measurement mechanism of Cyclictest can be
roughly described as shown in Fig. 2. The Cyclictest calls
a time-out API like sleep() and records the time difference
between the before and after of the API call with the system
clock. It evaluates the real-time responsiveness by calculat-
ing the latency, the time difference between the sleep time
the user requested, and the actual sleep time.
This tool does not require modification of the Linux ker-
nel, so we can port it and obtain the result easily. However,
the results from the Cyclictest do not show the real respon-
siveness that we want to measure. They just show the delay
that occurred due to the calling of the API. Such results are
not accurate enough because they do not include measure-
ment error due to such factors as the switching overhead
between user-space and kernel.
2.2 Realfeel
Realfeel [12] is a real-time measurement tool using an
RTC (Real-Time Clock). It measures the responsiveness
using a periodic interrupt of the RTC. Ideally, a user-level
Fig. 2 Measurement mechanism of Cyclictest
Peer-to-Peer Netw. Appl.
program should respond to interrupts periodically. However,
user-level programs respond later than expected. Realfeel
calculates each difference between the period and the actual
response interval; we call the difference jitter.
Figure 3 shows the measurement mechanism of Realfeel.
The RTC raises interrupts of which the period is already
decided. The user-level program obtains a timestamp for
each interrupt, but each interval is not exactly the same as
the period. Realfeel prints out all the jitters.
Realfeel runs at the user-level, like Cyclictest. Therefore,
we can use it without any modification of the Linux kernel.
However, Realfeel obtains timestamps from a machine-
specific performance counter included in the x86 processor
family. If we want to run it on another architecture such as
ARM or MIPS, we have to modify the source code to fit the
new architecture. Additionally, the results are not as accu-
rate as expected, because the measurement is not performed
at the kernel level.
2.3 Linux realtime benchmarking framework (LRTB)
LRTB is a real-time benchmark framework developed by
OPERSYS [13]. Supporters of I-pipe use LRTB to compare
its performance to that of Ingo Molnars real-time preemp-
tion patch when performance debate occurs in the Linux
kernel mailing list [17].
The LRTB mainly measures the various system calls
under heavy loads and the performance of each kernel sub-
system. Table 1 shows the items evaluated by the LRTB; the
items are categorized by the kernel subsystem.
The LRTB is good at evaluating the Linux kernel APIs
and functionality. It evaluates not only real-time responsive-
ness but also performance; we can obtain various measure-
ment results simultaneously. However, the LRTB requires 3
machines to execute (target, logger, and host are needed),
Fig. 3 Measurement mechanism of Realfeel
Table 1 Performance measurement items of LRTB
Kernel subsystem Performance measurement items
File system open(), close(), mmap(), select() call
execution time
Process management Scheduler Context Switching Time,
fork() Time, execve() Time,
Signal Transfer time
Network Local TCP, Unix Socket
Memory Memory access latency
so that it is not a convenient method with which to set up
testing the environment.
2.4 Hardware-based measurement methods
In the first stage of developing RTOS, most measurements
were performed with the assistance of hardware. Electrical
signals or software execution traces were sampled using the
ICE (In-Circuit Emulator) or the Logic Analyzer. Using col-
lected data, the real-time responsiveness can be measured
[16]. These hardware-based approaches can measure some
latencies more accurately and the developer can handle the
execution of software instruction by instruction.
However, these approaches have two main drawbacks.
One is the cost of the hardware. ICE and Logic Analyzer
are very expensive tools. The other is that these two tools
do not reflect the data in the CPU cache. These facilities see
the external bus traffic and are unable to see the contents
of the cache memory. For this reason, most hardware
approaches have been considered obsolete and software-
based approaches have appeared.
To utilize the advantages of both hardware- and software-
based approaches, customized hardware-based approaches
have been proposed. Latency Measurement Box [14] is
a good example of dedicated hardware that can measure
the responsiveness of a real-time Linux kernel. However,
dedicated hardware methods are still less convenient than
software-based approaches; the are also not cost-efficient.
2.5 Comparison with other software-based tools
Table 2 compares features of Cyclictest and Realfeel
with those of ELRM. Cyclictest simply utilizes schedul-
ing latency as responsiveness. Realfeel runs only on an x86
architecture and measures jitter between the RTC period
and the response interval of user-level task. As can be seen,
both tools measure the task scheduling latencies of the
user-level task scheduling and the difference between the
predefined period and the measured period. We think this
difference cannot be a metric that represents the real-time
responsiveness of systems.
 Peer-to-Peer Netw. Appl.

Table 2 Comparison with other real-time responsiveness measure- For this reason, we have had a hard time confirming that
ment tools the results indicate that the target system satisfies the real-
Cyclictest Realfeel ELRM time requirement. The second reason is that Cyclictest and
Realfeel only run on x86 CPU architecture, and so people
Measurement Scheduling Preemption have trouble determining the real-time responsiveness for
interval Latency Jitter Latency various mobile computing systems.
Interrupt Periodic Periodic We propose ELRM to solve these problems. ELRM
generation No programmed programmed needs to meet the condition that we mention below. First of
method via RTC from RTC all, the method must have a clear and intuitive definition for
HRT for RTC, RTC, CPU real-time responsiveness measurement intervals. Second,
Requirement measurement RDTSC in performance the method needs to be portable for various architectures.
accuracy x86 CPU counter Finally, a good usability is essential.
We now suggest a clear and intuitive definition for real-
time responsiveness measurement intervals. Then, we show
that the meaning of each interval is suitable for precise
measurement. Also, we describe our measurement method
On the other hand, ELRM is already working on x86 and
and our skeleton for easy-implementation in Linux-based
ARM architectures. ELRM is hardware dependent because
mobile computing systems.
it uses the clock counter of the processor. However, ELRM
makes use of the RTC and the performance counter, which
are already well-known, and the skeleton makes porting 3.1 Real-time responsiveness measurement interval
easier. ELRM measures the Preemption Latency as the
responsiveness of real-time systems; this yields the actual As we explained above, unclear definition of the real-time
response latency of an interrupt. measurement intervals can confuse developers. For exam-
ple, some interpret the scheduling latency as just the time
for task scheduling. On the other hand, scheduling latency
3 Real-time responsiveness measurement method can refer to the interval from the interrupt invocation to the
tasks running.
The real-time responsiveness measurement tools we have so We define the measurement interval for real-time respon-
far mentioned are widely used for various purposes. How- siveness measurement. As can be seen in Fig. 4, we define
ever, they have limitations for measuring exact, real-time Preemption latency as the measurement interval. Pre-
responsiveness. The first problem is that their measurement emption latency is defined as the time from the interrupt
results are not obvious since they do not clearly define invocation (A) to the start of the task related to the interrupt
the interval that they are willing to measure. For instance, (F). This latency is one of the most important components
Cyclictest and Realfeel do not state clearly in which inter- of real-time responsiveness.
val the tools measure the results. In other words, it is hard to In general, the interrupt wakes up the highest priority
establish criteria for real-time requirements with these tools. task, and the task is scheduled. If the task related to the

Kernel Mode User Mode

Preemption Latency

Hardware
Interrupt Real-Time
Latency or
Interrupt Handler
Mode Higher
Duration
Switch Priority
Scheduler Latency Latency task runs
Scheduling
Latency

Hardware Interrupt Interrupt Handler Interrupt Handler Scheduler Scheduler User Mode Time
Raise (A) Starts (B) Ends (C) Starts (D) Ends (E) Task Start (F)

Fig. 4 Real-time responsiveness measurement intervals

Peer-to-Peer Netw. Appl.

interrupt has lower priority than the current task, the current
task executes continuously, so that we need not consider this
situation.
First, we divide the preemption latency into 5 intervals;
we describe each interval below.
1. Hardware Interrupt Latency: This is from hardware
interrupt invocation (A) to the start of interrupt han-
dler (B). It consists of hardware delay, interrupt request
off-time, interrupt vectoring and dispatch.
2. Interrupt Handler Duration: From (B) to (C), this is time
consumed by the interrupt handler; it is often called
interrupt handler latency.
3. Scheduler Latency: This means the delay between the
end of the interrupt handling and the start of the sched-
uler, from (C) to (D) in Fig. 5.
4. Scheduling Latency: From (D) to (E), this means the
schedulers consumption for the scheduled task and the
context switching delay.
5. Mode Switch Latency: From (E) to (F), this is the
switch time from the kernel mode to the user mode after
task scheduling.
can even reach 1 sec. Therefore, we decided to ignore the
hardware interrupt latency.
3.2 Measurement method for real-time systems
Our method can be divided as follows: measurement in user
mode (UM part) and measurement in kernel mode (KM
part). In the UM part, we create a real-time task and some
normal tasks. While normal tasks run, the real-time task
ordinarily sleeps. When a periodic interrupt is raised by the
RTC, the real-time task wakes up and records the current
time. In the KM part, the current time is recorded when
the RTC interrupt handler gets control. Before the measure-
ment, the resolution (frequency of interrupt) of the RTC
must be set. Generally, we can set the resolution in the RTC
and in the Linux kernels setting; it can be set between 1 Hz
and 2048 Hz. The period of the interrupt is the inverse num-
ber of the resolution. For example, an RTC that has 1024 Hz
resolution invokes interrupts every 977 microseconds.
The mechanism of our measurement method is shown in
Fig. 5; operations for each interval are as follows:

Among these intervals, the hardware interrupt latency Point A: Up to point A, normal tasks are executed and
has a fixed amount less than 10 microseconds-and is not the real-time task is in the sleep state. At point A, the
very important compared to the other sorts of delay because RTC invokes a periodic interrupt and normal tasks are
total preemption latency is more than 100 microsecond and preempted by the interrupt.

(A) (B) (C) (D) (E) (F)

Time
Interval
Real-Time
or Kernel Mode User Mode
Higher Priority
Task Slept

Real-Time
Task wakes-up and goes to Run Queue or
Higher Priority
Non Real-Time Task Runs
or
Lower Priority
Task Runs Preemption Latency = TimeStamp B TimeStamp A

CPU Hardware
Interrupt Timestamp A Timestamp B
Preemption
Latency
Interrupt Handler
Duration Mode
Switch
RTC Interrupt Scheduler Latency Latency
Periodic Scheduling
Handler
Hardware Latency
Interrupt Occur

Time

External Periodic 2 3 5 6 Time Period

1 4
Event(Interrupt) 1/x sec
Using by RTC
(Real-Time Clock) X is the resolution of RTC (ex, 1000HZ means 1msec)

Fig. 5 Time line of real-time responsiveness measurement method

 Peer-to-Peer Netw. Appl.

Interval AB: This is a Hardware Interrupt Latency. In
our method, no additional operation is executed.
Interval BC: This is the Interrupt Handler Dura-
tion;the RTC interrupt handler is running during this
interval. At point C, the kernel can recognize the
interrupt invocation and the current time is stored in
Timestamp A(TS A), which is the starting point of Pre-
emption Latency. Next, the sleeping real-time task is
awakened at the end of the RTC interrupt handler; it is
inserted to run the queue to obtain the CPU.
Interval DG: These are called Scheduler Latency
(DE), Scheduling Latency (EF), and Mode Switch
Latency (FG). In our method, no additional operation
is executed.
Point G: Real-time task gets scheduled and the prepa-
ration to start is completed. Before the task starts, the
current time is stored in Timestamp B(TS B), which is
the end point of the Preemption Latency.
When all these steps are over, we can calculate the
Preemption Latency.
P reemption Latency = T S B T S A
In this way, we can measure the real-time responsiveness
by obtaining the Preemption Latency data for every periodic
interrupt.
In the next subsection, the skeleton will be described in
more detail.
Intuitive measurement result: ELRM supports for intu-
itive and easy-to-understand measurement results by
using Preemption Latency.
Portability: ELRM requires only the RTC and the
clock counter in the CPU. This means that ELRM can
be applied to most embedded systems, because the
RTC is an essential component of embedded systems
and most modern processors embed their own clock
counters.
3.4 Measurement system skeleton
ELRM offers a skeleton to support portability and usabil-
ity for various embedded systems. There are several aspects
that can influence the measurement results. The skeleton
provides reliability of measurement results with considera-
tion of these aspects.
Linux employs swapping for the memory system. How-
ever, swapping during measurement can result in distortion.
For this reason, the ELRM skeleton makes an explicit
suggestion that developers lock the memory during mea-
surement for clear results. The other constraints that could
skew the results are described below in detail.
We introduce the measurement system skeleton, which
can be helpful in adapting ELRM to various embedded sys-
tems. Figure 6 shows structure of our skeleton. We need two

3.3 Features

Ideally, the mesurement method for the real-time respon-

siveness measurement of the Linux-based embedded system
needs to support accurate results and easy-implementation
without any external precise measurement instrument. In
addition, it would be better if the method were applica-
ble to every kind of embedded processor. However, there is
no ideal measurement tool that can support everything that
we mentioned above. Thus, every real-time responsiveness
measurement tool has its own pros and cons, as does ELRM.
Now, we will explain some features of our measurement
method:
Simple organization of the measurement system: We
can measure the real-time responsiveness directly in
the target system without the help of any external
instrument.
High degree of accuracy and precision: Using the
processors clock counter and the interrupt of target sys-
tem provides accurate and fine-grained measurement
results.
Skeleton for easy implementation: Developers can
implement their real-time system easily with ELRMs
skeleton for the various embedded CPU architectures. Fig. 6 Control flow of measurement method skeleton
Peer-to-Peer Netw. Appl.

Table 3 Evaluation environment summary invoked, user mode is switched to kernel mode and
RTC interrupt handler starts.
Architecture x86 ARM
7. After completing interrupt handling, we save current
Target Board VIA C3 Nehemia SMDK6410 time as Timestamp A, the start time of the preemption
CPU Frequency 1GHz ARM1176 520MHz latency, at which the periodic interrupt occurs.
Memory 256MB 256MB 8. In rtc read () function, transfer Timestamp A to user
Version 2.6.15.2 2.6.21.5 mode using put user API provided.
Vanilla, Vanilla, 9. After obtaining data from the RTC, the real-time task
Voluntary Real-Time wakes up and continues running in user mode. At
Kernel Preemption Preemption this point, task records current time using the clock
Configuration Preemptible, counter. This is Timestamp B.
Real-Time 10. Calculate Preemption Latency by subtracting time dif-
Preemption ference between Timestamp A and Timestamp B.
11. Accumulate the results to generate statistics
Time 1 hour 12. Go back to step 5 and repeat the loop until receiving
Workload Hackbench 20 termination signal.

This skeleton makes it easier for developers to apply

programs: one runs in user mode and the other in kernel
mode.
1. Measurement begins in user mode. First of all, mem-
ory lock is acquired to prohibit swapping. Because
swapping can break the integrity of measurement
results, memory lock must be held until the measure-
ment ends.
2. We give real-time priority to the task that periodic
interrupt will wake up. This task is called the real-time
task.
3. Calibrate measurement time to maintain the system
integrity.
4. Set RTC to periodic interrupt mode using the ioctl()
system call.
5. Real-time task calls the read () system to read data
from the RTC. As a result, the real-time task gets
blocked. This read () system call always blocks the
caller process because the RTC data must be read
directly from the RTC chip.
6. After the real-time task is blocked, normal tasks exe-
cute until interrupt occurs. When the interrupt is
ELRM to various embedded systems. However, how to mea-
sure the Preemption Latency must be considered before
applying the measurement method proposed in this paper.
As we mentioned, most modern processors have their own
clock counter. But developers should check whether the
counter is usable in user mode, because some processors
prohibit this. We have performed experiments on x86 and
ARM11 processors; we use the RDTSC (ReaD Time Stamp
Counter) operation to read the clock counter for the x86 and
mfc0 operations to read the clock counter for ARM11. Espe-
cially, over 90 % of 32bit embedded processors are from the
ARM processor family, so this method can be applied to a
lot of embedded systems.
4 Evaluation
In this section, we explain why our tool is a good way
to evaluate real-time systems by comparing ELRM with
Realfeel. We measure the real-time responsiveness of each
Linux kernel with ELRM.

Fig. 7 The experimental result

from ELRM and realfeel

a the result from ELRM b the result from Realfeel

 Peer-to-Peer Netw. Appl.

Table 4 Summarized preemption latencies of kernels (x86 architec-

ture, time unit : ms)

Avg. Min. Max.

preemption preemption preemption
latency latency latency

Vanilla Kernel 0.00789 0.00212 17.388

Voluntary
Preemption 0.00531 0.00214 17.972
Kernel
Preemptible
Kernel 0.00596 0.00230 5.272
Real-Time
Preemption 0.00672 0.00555 0.0338
Kernel
Fig. 8 Comparison between jitter and preemption latency

4.1 Test environment
We evaluate ELRM on x86 and ARM architectures. Table 3
shows details about the x86 and ARM environments.
We use a heavy workload because it is more meaning-
ful for real-time responsiveness measurement if we measure
worst-case values [15] than that if we measure best-case or
average case values. We use Hackbench as the workload.
Hackbench was developed by Ingo Molnar; the program
sends and receives predefined sized messages. The number
of sending and receiving tasks is decided by a parameter.
If the parameter is 20, this would create 800 sending and
receiving tasks. This is a well-known benchmark program
that is widely used for system performance measurement.
We choose Vanilla Kernel, which does not consider
real-time responsiveness, Voluntary Preemption Kernel [4],
Preemptible Kernel [5], and Real-Time Preemption Kernel
[8] for comparison.
4.2 Measurement result
At first, we compared Realfeel and ELRM experimentally.
Our environment is the x86 system described in Table 3,
because Realfeel runs only in x86. We exclude Cyclictest
due to its kernel dependency like High Resolution Timer
porting. The utilized kernel is a Real-Time Preemption Ker-
nel. We achieved evenly distributed Preemption Latency,
as shown in Fig. 7-(a), when we perform measurement
using ELRM. On the other hand, the experimental results
for Realfeel are shown in Fig. 7-(b). We can observe the
fluctuation of the jitter when we use Realfeel.
Realfeel measures the jitter, which is the difference
between the interrupt period and the response period of a
task. Even if the jitter is zero, this does not mean good
responsiveness. It is difficult to find a relation between the
jitter and our Preemption Latency. In Fig. 8, we present a
good example showing that jitter can be zero but the pre-
emption latency is still bad. Realfeel recognizes that this
case is real-time responsive. However, ELRM recognizes
that it is not real-time responsive when Preemption Latency
is 10 milliseconds, as is true in this case.
Because ELRM provides Preemption Latency that is an
actual measure of responsiveness, we can predict the worst
case latency and the average latency based on the log of
Preemption Latency. We can also analyze how stably the
system responds using the variance of Preemption Latency.
We expect that ELRM can be utilized as a new measurement
method.

Preemption Latency (msec) Preemption Latency (msec) Preemption Latency (msec) Preemption Latency (msec)

time time time time

a Vanilla Kernel b Volutary Preemption Kerne c Preemptible Kernel d Real-Time Preemption Kernel

Fig. 9 The preemption latency results of four linux kernels for x86 architecture
Peer-to-Peer Netw. Appl.
Table 5 Summarized preemption latencies of kernels (ARM architec-
ture, time unit : ms)
Avg. Min. Max.
preemption preemption preemption
latency latency latency
Vanilla
Kernel 0.742 0.022 7.633
Real-Time
Preemption 0.125 0.055 0.145
Kernel
Table 4 shows the results of real-time responsiveness
measurement by ELRM in x86. There are three categories
of Preemption Latency: the average case, minimum latency,
and maximum latency. The most important case is the
maximum Preemption Latency, because it shows that Pre-
emption Latency is bounded even in the worst case. The
results show that Real-Time Preemption Kernel has the
best real-time responsiveness 33 microseconds of maxi-
mum latency. Therefore, we can conclude that Real-Time
Preemption Kernel is suitable for a system that requires
real-time responsiveness of less than 100 microseconds.
The four graphs in Fig. 9 also show the measurement
results for the x86 architecture. The horizontal axes of the
graphs indicate time and the vertical axes indicate the mea-
sured Preemption Latency per period. The unit of Preemp-
tion Latency is milliseconds. The graphs show the tendency
of overall real-time responsiveness. Low and evenly dis-
tributed Preemption Latency means that the system is more
responsive. On the other hand, high and irregularly dis-
tributed Preemption Latency means that the kernel does
not fit with the real-time system. If the measurement data
fluctuates a lot, we cannot predict the worst case of Preemp-
tion Latency. In this case, we can conclude that the kernel
is even less responsive. Figure 9 shows that Ingo Molnars
Real-Time Preemption Kernel has less Preemption Latency
than any of the other kernels. Preemptible Kernel and
Voluntary Preemption Kernel are next. Vanilla Kernel has
the worst responsiveness. Real-Time Preemption Kernel has
Fig. 10 The preemption latency
results of two linux kernel for
ARM11
a Vanilla kernel
a latency less than a certain boundary. As a result, we can
conclude that Real-Time Preemption Kernel can be used for
hard real-time systems that have strict deadlines.
We can see the results for the ARM architecture in
Table 5. Vanilla Kernel has an 8-millisecond maximum
Preemption Latency; that value for Real-Time has 145
microseconds. So, we can conclude that Real-Time Preemp-
tion Kernel has improved real-time responsiveness dramati-
cally compared to that of Vanilla Kernel.
Figure 10 shows the overall situation of measurement on
ARM. Real-Time Preemption Kernel has constant latency
that bounds under a certain value. So, we now understand
that Real-Time Preemption Kernel is the better choice for
the ARM architecture.
5 Conclusion and future work
Linux-based mobile computing devices are becoming pop-
ular and the market shares of such devices have been
expanding. For this reason, demand for real-time features is
increasing in many mobile computing systems that are com-
posed of the P2P cloud systems. Although researchers have
made efforts to improve real-time responsiveness, they still
have difficulties in developing Linux-based mobile com-
puting systems with real-time features due to the lack of
a standard measurement method that can assist them in
inspecting how well the real-time features are supported.
For this reason, in this paper we have proposed a defi-
nition of time intervals for real-time responsiveness and a
new method for the practical measurement of that respon-
siveness. We have investigated strengths and weaknesses
through comparison and analysis with existing measure-
ment tools. In addition, we have performed measurements
and evaluations of the mobile computing systems with our
measurement method. The investigation shows that ELRM
brought us a higher degree of precision and accuracy with
the RTC and the clock counter. ELRM also has a sim-
ple system structure and yields clear measurement results.
Therefore, we conclude that ELRM is original and has
convenient features.
b Real-time Preemption kernel
 Peer-to-Peer Netw. Appl.

Our future work will deal with the standardization Yung-Joon Jung received the
BS degrees in Physics from,
of the real-time responsiveness test environment. As we Hankuk University of For-
mentioned, differences in settings can affect experimental eign Studies, Seoul, Korea in
results. We hope that our standard can be a good reference 1997 and received the MS
for the people who are having trouble establish ing a test degrees in Computer Science
from same University in 1999.
environment. Since 1999, he was with
Ohsung Inc., venture com-
pany of intelligent transporta-
tion system(ITS) fields, Korea
References from 1999 to 2000 as a system
software engineer. Since 2001,
1. Yodaiken V (1999) The RTLinux manifesto In:Proceedings of the he has been with Electronics
5th Linux Expo and Telecommunications Research Institute (ETRI), Korea, as a senior
2. Bobet D, Cesati M (2005) Process scheduling, understanding the member of research staff. His research interests are embedded oper-
Linux Kernel, Chapter 7 ating system, real-time distributed computing and power management
3. Aas J (2005) Understanding the Linux 2.6.8.1 CPU scheduler. system.
Silicon Graphics, Inc.(SGI)
4. van Gend K (2006) Real-Time Linux patches: History and usage.
FOSDEM Donghyouk Lim received
5. Love R (2002) Lowering latency in Linux: Introducing a pre- the B.S. and M.S. degrees
emptible Kernel. Linux Journal in Computer Science from
6. Real-Time and Linux (2002) Part 2: The preemptible kernel by Korea Advanced Institute
Linux Devices. ELJOnline of Science and Technology
7. Timesys Whitepaper (2002) : A timesys perspective on the linux (KAIST), Daejeon, Korea in
preemptible kernel 2003 and 2005, respectively.
8. Heursch AC, Grambow D, Horstkotte A, Rzehak H (2003) Steps Since 2005, he has been with
towards a fully preemptable linux kernel. The proceedings of the Electronics and Telecommu-
workshop on real-time programming. Lagowski Park, Poland nications Research Institute
9. Kang D, Lee W, Park C (2007) Kernel thread scheduling in real- (ETRI), Korea, as a member
time linux for wearable computers. ETRI J 29(3):270280 of research staff. His research
10. Arthur S, Emde C, Mc Guire N (2007) Assessment of the real- interests are operating sys-
time preemption patches (RT-Preempt) and their impact on the tems, real-time systems and
general purpose performance of the system, 9th Real-Time Linux power-aware computing.
Workshop
11. Bauer A (2007) Realtime capabilities of low-end PowerPC and
ARM boards for embedded systems. Real-Time Linux Workshop
12. Webber A (2002) Realfeel test of the preemptible kernel patch. Yong Bon Koo received his
Linux Journal B.S. and M.S. degrees in Com-
13. Linux RT benchmarking framework. http://www.opersys.com/ puter Science from Korean
lrtbf/ Advanced Institute of Science
14. OSADL project: Latency measurement box. http://www.osadl. and Technology (KAIST).
org/Latency-Box.projects-latency-box.0.html He is now an engineer for
15. Regnier P, Lima G, Barreto L (2008) Evaluation of interrupt Electronics and Telecommu-
handling timeliness in real-time linux operating systems. ACM nications Research Institute
SIGOPS Oper Syst Rev 42(6):5364 (ETRI). His research interest
16. Measuring performance for real-time systems. http:// covers operating systems and
www.freescale.com/files/soft dev tools/doc/white paper/ mobile ecosystems.
CWPERFORMWP.pdf
17. PREEMPT RT and I-PIPE: The numbers, part 2. http://lwn.net/
Articles/140596/
Peer-to-Peer Netw. Appl.

Eun-Ser Lee received Ph.D. Hoon Choi (M92, SM09)

in Computer science from received the B.S.E.E degree in
Chung Ang University, Korea. computing engineering from
He is currently associate the Seoul National University,
professor of Computer Engi- Korea in 1983 and the M.S.
neering at Andong National and Ph.D degrees in computer
University, Korea. His main science from Duke University
research interests include in 1990 and 1993, respec-
software engineering and pro- tively. Before joining the
cess management, Ubiquitous Chungnam National Univer-
Computing. sity in 1996, he was a senior
member of technical staff of
Electronics and Telecommu-
nication Research Institute,
Korea since 1983, where he worked on LAN, broadband ISDN and
high-speed network system, His research area is the mobile, dis-
tributed computing. He has been involved in several research projects
on middleware for distributed computing, mobile computing and a
software platform of the cellular phone for wireless applications. He is
currently interested in autonomic computing and the system software
for wearable computers.