Comparison with the Linux scheduler
Experiment n.2: Real Time Java Application
We use a Java real-time application, RTApp,
whose only purpose is emulating behavior of many multimedia or control
applications, in that it activates a thread periodically that makes
some computations then sleeps until the next activation (period is
40ms by default, but may be provided in ms as an optional command-line
parameter). Actually, RTApp measures the difference (in ms) between
the activation instant of the periodic thread and the ideal one as
derived from the timer period. It displays the average and maximum
absolute difference experienced during the last 16 activations.
This is the output when only one instance of the program is running
indisturbed:
[tommaso@mobiletom:~/tests] sudo nice -n -19 java RTApp
avg dt=4, avg qdt=4, max qdt=4
avg dt=4, avg qdt=4, max qdt=4
avg dt=4, avg qdt=4, max qdt=4
[...]
Application does not experience fluctuations of the activation instant
above the millisecond. Of course, activating other Linux activities
at default priority (nice 0) does not affect the running RTApp instance.
On the other hand, this is the output while activating a second instance
of RTApp (emulating e.g. a second RT application in the system):
[tommaso@mobiletom:~/tests] sudo nice -n -19 java RTApp
[...]
avg dt=3, avg qdt=4, max qdt=4
avg dt=4, avg qdt=11, max qdt=92
avg dt=4, avg qdt=4, max qdt=7
avg dt=4, avg qdt=4, max qdt=8
avg dt=4, avg qdt=4, max qdt=4
avg dt=4, avg qdt=4, max qdt=4
[...]
The peak is experienced during the boot of the second RTApp instance.
As shown by the experiment, fluctuation in the activation instant may
be higher than twice the application period itself, causing possible
malfunctions of the application, unless appropriate techniques are
used (for instance, for a multimedia application, we would need at
least two buffer elements at the output of the periodic thread, what
would increase the application latency).
When using AQuoSA rsource reservations, it is possible to isolate
temporally each instance of RTApp so that it is not disturbed by
other Linux applications, and the interference due to other RTApp
instances is kept in check through appropriate CPU reservation
(contract) parameters.
This is the output of RTApp while activating a second instance
of itself, both of which have been launched through the qres_wrap
command-line tool so to reserve 25 percent of the cpu:
[tommaso@mobiletom:~/tests] qres_wrap 10000 10000 40000 java RTApp
[...]
avg dt=4, avg qdt=4, max qdt=4
avg dt=4, avg qdt=5, max qdt=11
avg dt=4, avg qdt=3, max qdt=4
avg dt=4, avg qdt=4, max qdt=4
[...]
Again, the peak corresponds to the instant of activation of the
second RTApp instance, but the fluctuation in the activation instant
of the first RTApp instance is kept in check by the scheduler and
remains below the application period, thus the operating system
provides to the application the promised guarantees.
|
