1. Introduction. 2. Tests. 2.1 Hardware Tests Test modality

(1)

1. Introduction

In this article we want to expose the results of a benchmark concerning real time performances of three RTOS: VRTXsa, RTAI and RTLinux.

The goal of the project was to evaluate the possibility to migrate the operating system of an embedded telecommunication SBC from VRTXsa to a linux based one.

This project has been realized as thesis work for a famous telecommunication company and has evolved under the supervision of the Rome’s University “La Sapienza”.

2. Tests

We executed hardware tests and software tests with different modalities to evaluate all parameters described above. This is the platform we used to execute these tests:

Motorola Freescale PQ2FADS-VR

CPU: PowerPc 8275 @ 200 Mhz - bus 66 Mhz. RAM: 32 Mb

FLASH: 8 Mb.

Tests have been executed without load and with two different load solutions in order to evaluate differences between the executions in relationship with the changing load.

2.1 Hardware Tests

In hardware tests we use oscilloscope to measure hardware latency time: time which elapses between the generation of an interrupt and the moment its handler starts.

2.1.1 Test modality

Hardware test have been done using oscilloscope. We made a little hardware modification: we built a bridge between LD13 led and C11 pin (of system expansion connector). C11 pin is the interrupt request pin and is connected with irq 6 signal (DP6/CSE0/IRQ6#). Connection created between LD13 led and C11 pin is fundamental to reply infinitely the interrupt generation and its handling. Test program uses LD13 led pin to generate tension levels of +5V/0V. Installing a new Interrupt Service Routine on interrupt 6 is possible to handle this interrupt. Turning on LD13 led we’ll get a transition High Low of the tension level. Such event generate interrupt 6 and handler is started. The handler we defined will turn off, and on afterwards, LD13 led generating in this way a new interrupt and so on. In this way an infinite sequence of interrupt is generated. Applying the oscilloscope probe on the connection it’s possible to analyse the wave form and to estimate with a good precision the time which elapses between the event and its handler starting. This time includes hardware latency and interrupt latency.

(2)

2.1.2 RTAI Measurements

(3)

(4)

(5)

2.1.3 RTLinux Measurements

(6)

(7)

(8)

2.1.4 VRTXsa Measurements

(9)

Figure 8 - VRTXsa: Measure of minimum IRQ latency

(10)

Figure 9 - VRTXsa: Measure of maximum IRQ variation

2.1.5 Results analysis

We compiled the following graph to understand and analyse the data collected:

680 530 1110 350 170 600 330 360 510 0 200 400 600 800 1000 1200 la te nz e in n an os ec on di

Confronto latenza minima Massima e varianza IRQ

RTAI RTLinux VRTXsa

(11)

In a RTOS Variation should be minimized. The difference between the quickest execution and the slowest one has to tend to zero to have a predictable system.

RTAI is the best system with a value of 330 nanoseconds. RTLinux is 30 nanoseconds worst while VRTXsa reports even worst values overstepping 500 nanoseconds. A so high value in variation is given by some executions which raise the maximum latency value over one microsecond. The quickest executions instead report a time around the 600 nanoseconds.

Considering the efficiency VRTXsa surely is the slowest system with a maximum latency higher than a microsecond. RTLinux is the quickest system with a minimum latency lower than 200 nanoseconds. RTAI reaches intermediate values: it has a slightly more uniform values’ set and is able to get the best variation value, 30 nanoseconds lower than RTLinux, being so the most predictable system.

(12)

2.2 Software Tests

In software tests we measure ipc times using fifo queues and mailboxes.

We’re able to measure latency of fifo and mailboxes calls, “intratask” ipc times, and “intertask” ipc times plus context switching. We’re able to obtain context switch time too, confronting the previous results.

2.2.1 Efficiency

These tests measure the time spent by the operating system to execute some ipc calls.

LatencyFIFO is a test which measures latency times of a call which writes 4 bytes of data on a FIFO queue

Confronti latenza FIFO NS

8.383 6.495 53.647 5.765 51.434 664.337 0 1.000 2.000 3.000 4.000 5.000 6.000 7.000 la te nz a FI FO

(13)

Confronti latenza FIFO US 8.446 6.694 1.437.217 263.946 0 1.000 2.000 3.000 4.000 5.000 6.000 7.000 la te nz a FI FO

RTAI RTLinux VRTXsa Confronti latenza FIFO KS

8.507 9.235 8.992 8.992 9.052 3.731.295 1.439.693 0 1.000 2.000 3.000 4.000 5.000 6.000 7.000 la te nz a FI FO

RTAI RTLinux VRTXsa

VRTXsa is the slowest system reporting times near 5k nanoseconds. RTAI and RTLinux are much quicker: about 1k nanoseconds for RTAI and about 700 for RTLinux.

These times really are very good and very hard to maintain stable especially under stress, in rare occasions in fact RTAI graph shows some peaks around 9k nanoseconds. VRTXsa graphs don’t change very much: some peaks are present in the executions without stress, and these peaks increase in the executions under stress. RTLinux isn’t affected by the stress increment and it would have the lowest variation if we don’t consider a peak around 53k nanoseconds. This peak is a unique event and may be ignored as an anomaly. Fifo.c evaluates the time that a task spends to write and read a 4 bytes data block in a fifo queue.

(14)

Confronti efficienza FIFO NS - exec. 3 15.877 0 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.000 11.000 12.000 la te nz a FI FO

VRTXsa RTLinux RTAI

Confronti efficienza FIFO US - exec. 2

59.928 15.292 0 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.000 11.000 12.000 la te nz a FI FO

(15)

Confronti efficienza FIFO KS - exec. 2 12.018 59.711 15.354 0 1.000 2.000 3.000 4.000 5.000 6.000 7.000 8.000 9.000 10.000 11.000 12.000 la te nz a FI FO

VRTXsa RTLinux RTAI

RTAI reports times about 2k nanoseconds lower than RTLinux which has however the less perturbed graph and, consequently, a lower variation than RTAI. The best system, considering the graph perturbation, is VRTXsa, but it’s much slower than the other systems.

FifoCS.c runs two concurrent tasks synchronized on a FIFO queue used to exchange messages. The time measured is the sum of writing and reading time from fifo queue, synchronization time and context switch time.

Message is a struct of 16 bytes. VRTsa in this case moves only the address pointing to the struct, so only 4 bytes instead of 16. We have to consider this advantage while evaluating the following graphs.

Confronti IPC FIFO NS - exec. 3

116.783 157.229 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000 55.000 60.000 65.000 70.000 te m po IP C F IF O

(16)

Confronti IPC FIFO US - exec. 2 158.765 2.820.163 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000 55.000 60.000 65.000 70.000 te m po IP C F IF O

VRTXsa RTLinux RTAI

Confronti IPC FIFO KS - exec. 1

2.379.253 1.486.120 158.982 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000 55.000 60.000 65.000 70.000 te m po IP C F IF O

VRTXsa RTLinux RTAI

VRTXsa is still the slowest system but with less perturbed graph. It seem it isn’t affected by the stress increment: it shows peaks in all three executions although with different values.

Linux systems are more similar considering both variation and efficiency. Also in this case efficiency is constant if stress increases.

mbox.c runs two distinct tests: the first one measures the latency of a call writing a 16 bytes data block to a mailbox.

(17)

Confronti latenza mailboxes NS - exec. 1 17.442 0 500 1.000 1.500 2.000 2.500 3.000 3.500 4.000 4.500 5.000 5.500 6.000 6.500 7.000 la te nz a m ai lb ox es

VRTXsa RTLinux RTAI

Confronti latenza mailboxes US - exec. 2

17.564 0 500 1.000 1.500 2.000 2.500 3.000 3.500 4.000 4.500 5.000 5.500 6.000 6.500 7.000 la te nz a m ai lb ox es

(18)

Confronti latenza mailboxes KS - exec. 3911.620 12.713 17.683 0 500 1.000 1.500 2.000 2.500 3.000 3.500 4.000 4.500 5.000 5.500 6.000 6.500 7.000 la te nz a m ai lb ox es

VRTXsa RTLinux RTAI

RTLinux seems to be the quickest system and VRTXsa the slowest one.

RTAI is in the middle. RTAI’s graph seems to be the less perturbed followed by RTLinux and VRTXsa which report very high peaks.

RTAI seems to be much slower with stress in kernel space: it has a more perturbed graph. RTLinux instead is the system which isn’t affected by the stress increment. Efficiency is constant for all the three systems but VRTXsa variation increases very much as RTAI variation increases a little.

The second test is a mailboxes ipc test: two concurrent tasks exchange a message using a mailbox.

In this case time is the sum of writing and reading from mailbox, synchronization time and context switch time. Message is a struct of a 16 bytes data block. VRTXsa moves only the addresses of this messages, so only 4 bytes instead of 16. We have to consider this advantage while evaluating the following graphs.

(19)

Confronti IPC mailboxes NS - exec. 3 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000 55.000 60.000 te m po IP C m ai lb ox es

VRTXsa RTLinux RTAI

Confronti IPC mailboxes US - exec. 2

0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000 55.000 60.000 te m po IP C m ai lb ox es

(20)

Confronti IPC mailboxes KS - exec. 2 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000 55.000 60.000 te m po IP C m ai lb ox es

VRTXsa RTLinux RTAI

RTLinux is the quickest system in this case too and isn’t affected by the stress increment considering both variarion and efficiency. RTAI shows some peaks and a more perturbed graph if stress is increased.

VRTXsa is the slowest system but has the less perturbed graph. It reports some peak which cause a high variation value.

But we have to analyse better VRTXsa’s behaviour. In the executions under stress a big number of iterations reported values of about 10 milliseconds. In some cases it didn’t happened and in rare cases the whole execution of the test reported these values.

In some cases the concurrent VRTXsa tasks are synchronized in a bad way and a whole system tick (just 10 milliseconds) elapses between the composition of the message and its receiving.

(21)

DIAGRAMMI DI FLUSSO DI ESECUZIONE caso 1

OS: VRTXsa sorgente: mbox.c tipo di carico: assente

Il test calcola la differenza di tempo (in ns) che intercorre tra l’istante in cui il server crea il messaggio e l’istante in cui il client lo riceve.

Un messaggio inviato ad una mailbox con sc_post è immediatamente allocato ad un eventuale task che è in attesa sulla

mailbox. Il messaggio non è salvato nella mailbox in questo caso. Questo comportamento di VRTXsa fa in modo che al

tempo t3 il client abbia in realtà già ricevuto il messaggio che stava aspettando.

Dunque si avrà che:

Tempo IPC: (t3 - t1) = (δ1 + δ2) = ca. 45000 ns [0] server [1] client slice slice msg t1 pend t3 t2 post delay get δ δ

DIAGRAMMI DI FLUSSO DI ESECUZIONE caso 2

OS: VRTXsa sorgente: mbox.c tipo di carico: assente

Tempo IPC: (t3 - t1) = (δ1 + δ2) = ca. 45000 ns [0] server [1] client slice t1 get t3 t2 post delay pend δ δ msg

Such schemas show the normal synchronization possible between client task and server task in an execution without stress. In both cases at instant t1 message is composed by the server and at instant t3 message is read by the client.

(22)

In a stressed execution the scheduler has to manage three tasks.

It’s important to remember that these tasks are scheduled with a round robin time slice policy with a static fifo priority. Time slice can be set only to an integer multiple of the system tick, so minimum value is just one system tick = 10 milliseconds.

Stress task is the first task to be executed. When its slice is over scheduler will bring it to ready state and will run instead the server task. It may happens that its slice ends after server composed the message and just before it writes it on the mailbox, so message contains value t1.

Now scheduler will run client task which will execute immediately an sc_pend() call on mailbox. This call is blocking, so rescheduling procedure is started and scheduler will run the stress task according to fifo policy. Stress task will run for a time slice. After this period the server task will run again and it will write the message on the mailbox and then will wait on the synchronization semaphore.

Since client task was already waiting for the message, VRTXsa will move the message right from the server to the client.

So the elapsed time now will be the time between instant t4 and t1 and will comprehend a whole time slice: about 10 milliseconds.

The following schema tries to show what just described:

DIAGRAMMI DI FLUSSO DI ESECUZIONE

OS: VRTXsa sorgente: mbox.c tipo di carico: kernel mode

Un messaggio inviato ad una mailbox con sc_post è immediatamente allocato ad un eventuale task che è in attesa sulla

mailbox. Il messaggio non è salvato nella mailbox in questo caso. Questo comportamento di VRTXsa fa in modo che al

tempo t4 il client abbia in realtà già ricevuto il messaggio che stava aspettando.

Tempo IPC: (t4 - t1) = (1 slice + δ1 + δ2) = ca. 10000000 ns [0] stress

[1] server

[2] client

slice slice slice

msg t1 pend t3 t2 post delay t4 get δ δ

(23)

1.036 795 6.131 3.649 5. 812 9 .951 15.34 3 8.944 49.67 6 2.734 ₉₆6 6.603 13.88 2 8.967 46.92 9 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000

Confronti medie senza stress

RTAI RTLinux VRTXsa

latenza fifo efficienza fifo IPC fifo latenza mailboxes IPC mailboxes

1.039 683 7.925 3.802 5.8 25 9.8 64 15.10 3 9.001 51.82 7 2.727 1.179 7.923 13.71 6 9.001 1.021 .157 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000

Confronti medie con stress in user space

RTAI RTLinux VRTXsa

(24)

1.104 696 15.04 5 4.585 6.2 04 9.7 80 16.02 3 9.913 60.87 1 2.852 1.047 8.426 13.25 8 9.913 412.2 22 0 5.000 10.000 15.000 20.000 25.000 30.000 35.000 40.000 45.000 50.000

Confronti medie con stress in kernel space

RTAI RTLinux VRTXsa

We realized these graph to confront all the average values reported by every operating system in different tests. It’s evident the difference between VRTXsa, generally the slowest system, and linux based systems. RTLinux seems to be generally the quickest system.

The same values have been posed in relationship with stress to see immediately if there is influence of stress on the performances of a system. What is clear is that RTAI and RTLinux aren’t affected by the stress increment, while VRTXsa is affected in an evident way and proportionally to the kind of stress, especially in ipc tests.

(25)

1.036 1.039 1.104 3.6 49 3.802 4.585 15.34 3 15.10 3 16.02 3 2.734 2.727 2.852 13.88 2 13.71 6 13.25 8 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000

Confronti medie RTAI al variare dello stress

nessun carico stress in User Space stress in Kernel Space

795 683 696 5.812 5.825 6.204 8.9 44 9.001 9.9 13 966 1.179 1.047 8.967 9.001 9.9 13 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000

Confronti medie RTLinux al variare dello stress

(26)

6.131 7.9 2515 .045 9.951 9.864 9.780 49.67 6 51.82 760 .871 6.603 7.9 23 8.426 46.92 9 1.021 .157 412.2 22 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000

Confronti medie VRTXsa al variare dello stress

(27)

2.2.2 Predictability

We needed to create an index in order to measure the predictability of the system.

We considered the average value of the executions of every test and increased it of a value called tolerance threshold. SPI (System’s Predictability Index) is the percentage of executions which are below the threshold. general IPS value is the average of all IPS of every test with every stress condition. We used this data to paint the General IPS comparison graph. Following graphs are about the average IPS in relation with stress condition and about IPS of every single test for every operating system. 93,11 93,05 90,85 91,79 91,99 91,22 98 ,75 97,02 98,25 0,00 10,00 20,00 30,00 40,00 50,00 60,00 70,00 80,00 90,00 100,00

Confronto IPS medio al variare dello stress

RTAI NS RTAI US RTAI KS

RTLinux NS RTLinux US RTLinux KS

VRTXsa NS VRTXsa US VRTXsa KS

This graph confirm the higher predictability of VRTXsa. This parameter moreover is constant if stress is increased. RTAI seems to be slightly more predictable than RTLinux. Both linux systems have a low decrease of predictability if stress is increased.

92,34 _91,67 98,01 0,00 20,00 40,00 60,00 80,00 100,00

Confronto IPS generale

(28)

87,4 92,8 92,0 99,3 94,0 99,6 90,0 85,3 98,7 85,3 99,6 99,5 98,2 97,0 99,5

0

10

20

30

40

50

60

70

80

90

100 Confronto IPS medio al variare del test - Senza Stress

Latenza FIFO Efficienza FIFO IPC FIFO Latenza Mailboxes IPC Mailboxes

87,4 92,3 91,7 99,5 94,3 99,8 90,8 85,3 98,7 85,3 99,6 99,2 98,7 97,5 90,2

0

10

20

30

40

50

60

70

80

90

100 Confronto IPS medio al variare del test - Stress in User Space

Latenza FIFO Efficienza FIFO IPC FIFO Latenza Mailboxes IPC Mailboxes RTAI RTLinux VRTXsa

(29)

90,4 92,0 84,7 97,5 89,7 99,6 92,0 82,8 98,8 82,8 99,6 99,3 98,2 98,2 _96,0

0

10

20

30

40

50

60

70

80

90

100 Confronto IPS medio al variare del test - Stress in kernel Space

Latenza FIFO Efficienza FIFO IPC FIFO Latenza Mailboxes IPC Mailboxes With these graphs, one for every stress condition, we’re able to determine for every test which is the most predictable system. They confirm that VRTXsa is the most predictable one and that it is the less affected by stress increasing although there is a big IPC decrease in mailbox test if stress is increased.

Also linux systems generally are not very affected by stress increment, but they report a bigger IPS decrease in both ipc tests especially increasing the stress from user space to kernel space.

(30)

2.2.3 Variation

A very important parameter is the variation between the slowest and quickest execution times. So, for every test, we considered the extremis of the interval of returned values.

General Variation is the average of all variations of every test under every stress condition. We used this data to realize the graph of general variation comparison.

Following graphs are about average variation in function of stress conditions and about variation of every test for every operating system.

It’s possible to see, considering even only the general variation comparison graph, how worst is VRTXsa. This is because this operating system, although generally has a less perturbed graph, reports some very high peaks which increment the variation.

18 39 2 18 28 7 16 95 4 19 04 6 16 33 5 12 84 5 42 23 66 27 51 43 7 33 00 46 7 0 500000 1000000 1500000 2000000 2500000 3000000 3500000

Confronto Varianza media al variare dello stress

In this graph we related average variation with stress increment. It’s clear that Linux systems aren’t affected by stress increment instead of VRTXsa.

It seems that linux based systems report a lower variation if stress is incremented. Actually what happens is that a quick system without stress is able to get very quick executions and some slower executions. If stress is increased a RTOS won’t overstep the limit of the slowest executions: the result is that fastest executions will be slowed down while slowest executions will generally be constant, and the variation between slowest and quickest execution will be lower. The following schema will explain better the idea:

KS NS

Figure 10 – Variation difference between different stress loaded test

17 87 8 16 07 6 ₂₁58 09 0 0 500000 1000000 1500000 2000000 2500000

Confronto Varianza generale

(31)

Generally VRTXsa has less perturbed graphs, and tends to a lower variation. But it reports some peaks in some executions. Since these peaks are proportional to the stress increment the result is that variation grew up very quickly. 7. 45 4 13 .5 96 29 .1 32 14 .9 10 26 .8 69 53 .0 31 7. 07 0 15 .0 71 4. 46 5 15 .5 96 65 9. 71 0 1. 98 8 78 5. 98 2 17 1. 37 3 49 2. 77 7 0 100.000 200.000 300.000 400.000 500.000 600.000 700.000 800.000

Confronto Varianza media al variare del test - Senza Stress

Latenza FIFO Efficienza FIFO IPC FIFO Latenza Mailboxes IPC Mailboxes RTAI RTLinux VRTXsa

(32)

7. 45 5 13 .2 73 28 .7 67 15 .1 52 26 .7 88 6. 12 1 6. 30 3 14 .6 47 39 .9 60 14 .6 47 1. 43 2. 73 5 34 .1 87 1. 32 7. 72 3 52 0. 05 4 10 .4 42 .4 88 0 2.000.000 4.000.000 6.000.000 8.000.000 10.000.000 12.000.000

Confronto Varianza media al variare del test - Stress in User Space

Latenza FIFO Efficienza FIFO IPC FIFO Latenza Mailboxes IPC Mailboxes

8. 24 3 13 .8 79 25 .0 51 14 .8 49 22 .7 47 5. 33 3 7. 01 0 20 .2 83 11 .3 14 20 .2 83 3. 72 6. 66 8 18 .2 96 1. 73 6. 00 0 53 7. 50 6 10 .4 83 .8 67 0 2.000.000 4.000.000 6.000.000 8.000.000 10.000.000 12.000.000

Confronto Varianza media al variare del test - Stress in kernel Space

Latenza FIFO Efficienza FIFO IPC FIFO Latenza Mailboxes IPC Mailboxes With these graphs is possible to evaluate variation of every operating system for every test.

RTAI RTLinux VRTXsa

(33)

It is also possible to verify variation changing for every single test in relation with stress increment.

These graphs confirm that VRTXsa is the system with the highest variation and the most affected by stress increment. We have also to note that the first graph and the following two have a different scale.

(34)

2.2.4 Context Switch Time

Context Switch Time (CST) is a value that measures time spent by an operating system to complete the transition of the currently executing task from executing state to ready state and inverse transition of another task ready to be executed.

This operation should take a constant time on a RTOS.

Is value has not been directly measured, but is derived from reprocessing of data already collected using fifo and fifoCS tests.

If we detract values obtained from fifo.c from measurement returned from fifoCS.c we’ll get an indicative measurement of CST. 11694 ₁₁₃₀₁ 11438 3132 3176 3709 39725 41963 51091 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 50000 55000

Confronto CST medio al variare dello stress

In this graph is clear that CST times are nearly constant in linux systems but they increase clearly in VRTXsa when stress is increased.

The next graph instead reports in percentage the impact of CST and of overhead IPC intratask on the value returned from fifoCS.c.

We don’t have to read from the following graph that RTAI is a system that takes less time to execute the context switch if under stress. We can understand instead that IPC intratask overhead graves proportionally more on the total time than the CST in the case of kernel space stress.

It’s mode interesting to consider that, proportionally on the time reported by fifoCS.c, VRTXsa takes more time to execute context switch than linux based systems. Actually RTLinux seems to be the system which in proportion takes less time to switch the context: the time spent by RTLinux to switch from a task to another one is about the 35% of the time reported by fifoCS.c without differences depending from stress. The 65% of the time is spent to execute the IPC intratask. This data confirms what already seen in the efficiency comparison graphs where RTLinux was slower than RTAI undepending by the stress.

VRTXsa takes the 80% of the time to switch the context and finally RTAI takes about the 75% of time reported by fifoCS.c.

Differences related to stress increments are unimportant except for the case of RTAI in kernel space: in this test IPC intratask overhead graves more.

(35)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Confronto rapporto CST/IPC al variare dello stress

CST RTAI NS CST RTAI US CST RTAI KS

CST RTlinux NS CST RTLinux US CST RTLinux KS

CST VRTXsa NS CST VRTXsa US CST VRTXsa KS

(36)

2.3 Final Comparisons

Efficiency, Variation and Predictability are the three main parameters we detected to evaluate performances of a RTOS. Therefore we prepared some summary graphs just to put together these values.

Variation is on x axis, efficiency on y axis (as execution average time). Each operating system is represented by a sphere which radius is its predictability.

The optimum operating system is then the one that minimizes variation and execution times and maximizes the predictability. It will be represented by a sphere of maximum radius (100) situated just in the origin of axes.

Confronto di Sintesi per latenza FIFO senza Stress

-2.000 3.000 8.000 13.000 18.000 -400.000 100.000 600.000 1.100.000 1.600.000 2.100.000 2.600.000 3.100.000 3.600.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

Confronto di Sintesi per latenza FIFO con stress in User Space

-2.000 3.000 8.000 13.000 18.000 -400.000 100.000 600.000 1.100.000 1.600.000 2.100.000 2.600.000 3.100.000 3.600.000 Varianza M ed ia te m pi

(37)

Confronto di Sintesi per latenza FIFO con stress in Kernel Space -2.000 3.000 8.000 13.000 18.000 -400.000 600.000 1.600.000 2.600.000 3.600.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

It’s evident in these first three graphs the VRTXsa worsening if stress is increased, while performances of the other systems are nearly constant.

About predictability all the systems are comparable.

Confronto di Sintesi per efficienza FIFO - senza Stress

0 2.000 4.000 6.000 8.000 10.000 12.000 -1.000 4.000 9.000 14.000 19.000 24.000 29.000 34.000 39.000 Varianza M ed ia te m pi

(38)

Confronto di Sintesi per efficienza FIFO con stress in User Space 0 2.000 4.000 6.000 8.000 10.000 12.000 -1.000 4.000 9.000 14.000 19.000 24.000 29.000 34.000 39.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

Confronto di Sintesi per efficienza FIFO con stress in Kernel Space

0 2.000 4.000 6.000 8.000 10.000 12.000 -1.000 4.000 9.000 14.000 19.000 24.000 29.000 34.000 39.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

Also in this case linux based system report constant variation, efficiency and predictability. RTLinux is the best system about variation. RTAI instead is the best about efficiency.

(39)

Confronto di Sintesi per IPC con FIFO - senza Stress -10.000 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000 -200.000 300.000 800.000 1.300.000 1.800.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

Confronto di Sintesi per IPC con FIFO con stress in User Space

-10.000 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000 -200.000 300.000 800.000 1.300.000 1.800.000 Varianza M ed ia te m pi

(40)

Confronto di Sintesi per IPC con FIFO con stress in Kernel Space -10.000 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000 80.000 -200.000 300.000 800.000 1.300.000 1.800.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

First of all we have to consider the different scale of these three graphs. VRTXsa is very far from the origin and it still moves away increasing the stress. In these, and the following graphs linux systems are always situated very close to the origin instead of VRTXsa. About predictability all systems are comparable.

Confronto di Sintesi per latenza mailboxes - senza Stress

-10.000 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000 -100.000 0 100.000 200.000 300.000 400.000 500.000 600.000 700.000 800.000 Varianza M ed ia te m pi

(41)

Confronto di Sintesi per latenza mailboxes con stress in User Space -10.000 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000 -100.000 0 100.000 200.000 300.000 400.000 500.000 600.000 700.000 800.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

Confronto di Sintesi per latenza mailboxes con stress in Kernel Space

-10.000 0 10.000 20.000 30.000 40.000 50.000 60.000 70.000 -100.000 0 100.000 200.000 300.000 400.000 500.000 600.000 700.000 800.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

About efficiency and predictability all the systems are comparable. VRTXsa is a little bit slower but the main fact is that it reports a variation worsening if stress is increased.

(42)

Confronto di Sintesi per IPC con mailboxes - senza Stress -200.000 0 200.000 400.000 600.000 800.000 1.000.000 1.200.000 -2.000.000 0 2.000.000 4.000.000 6.000.000 8.000.000 10.000.000 12.000.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

Confronto di Sintesi per IPC con mailboxes con stress in User Space

-200.000 0 200.000 400.000 600.000 800.000 1.000.000 1.200.000 -2.000.000 0 2.000.000 4.000.000 6.000.000 8.000.000 10.000.000 12.000.000 Varianza M ed ia te m pi

(43)

Confronto di Sintesi per IPC con mailboxes con stress in Kernel Space -200.000 0 200.000 400.000 600.000 800.000 1.000.000 1.200.000 -2.000.000 0 2.000.000 4.000.000 6.000.000 8.000.000 10.000.000 12.000.000 Varianza M ed ia te m pi

RTAI RTLinux VRTXsa

The scale of these graphs may let think that the systems are comparable at least without stress.

Instead about variation and efficiency VRTXsa has worst performances. RTLinux and RTAI are aligned about variation and efficiency but RTAI is better about predictability.

Once again is evident the VRTXsa performance worsening related to the stress increasing.

3. Conclusions

It seems generally clear that linux systems are more performing considering efficiency while VRTXsa has the less perturbed graph.

It seem evident that linux systems are the best choice considering the following facts: - maximum efficiency values are always lower than VRTXsa minimum values - linux based systems peaks are more frequent but more modest than VRTXsa ones

- VRTXsa in ipc tests has the advantage of managing a quarter the data linux manages (4 bytes against 16)

Considering all these facts and what analysed previously, it seems that linux based systems are the best solution and that such systems can be a valid and more efficient alternative to VRTXsa. Therefore would be surely advisable a migration from VRTXsa to a linux based real time system.