Measuring Erika OS Api runtime

Forum related to ERIKA Enterprise and RT-Druid version 2

Moderator: paolo.gai

Post Reply
erjola.lalo
Newbie
Posts: 1
Joined: Mon Mar 14, 2016 10:59 am

Measuring Erika OS Api runtime

Post by erjola.lalo » Mon Mar 14, 2016 11:51 am

Hi,

I am Erjola Lalo and I work at Timing Architects. My colleague Felix Martin recommended me that I write here for any question I might have regarding Erika OS.

I currently am doing some research on the field of scheduling. At this phase I am focused on cooperative scheduling, where I intent to provide methodologies/heuristics/algorithms how to configure/design in a "near-optimal" way the parameters as task groups and schedule points for cooperative scheduling in order to reduce preemption overheads and maintain the schedulability.

I'm using in my case studies the ERIKA OS and I intend to measure the run-time it takes for OS API such as: Activate Task, Terminate, Schedule API, context switching, etc. I need this information for creating an OS model with overheads which I can use during system simulation (in a model based approach) in order to see how the influence of overheads is in the system. The measuring step of overhead and target verification of the scheduling design is a step i will continuously do as well in the future phases of my research regarding multi-core scheduling.

For the measurements I am using Lauterbach Trace, where am using the approach of setting markers for the OS APIs and trace them as well. In this way I can get the information when the API is started and terminated, and get this way the run-time. For certain API: Activate, Terminate, Set/wait/Clear Event I have already successfully retrieved some run-times, but for some others I haven't found yet the API name. I have observed the source code of Erika OS, but at some parts is confusing for me :).

My questions are as following:
1- How is the cooperative scheduling correctly configured in oil.config file? I have for instance 2 cooperative tasks (i.e. belonging in the same cooperative group). The lower priority task in the group is "preempted" only when the Schedule() Api is called. Should i create one Internal resource (representing this task group) and assign to these 2 tasks in their configuration e.g. RESOURCE = RES_1; and set their schedule to SCHEDULE = NON;? As I have seen during my measurements, the results were not correctly. Therefore, most probably I am doing something wrong.
2- What is the Api for the Request/Release of the semaphore or splinlock?
3- Is there any OS System Call in the context of which the OS API are executed? This is very beneficial to have an correct/importable trace in TA Inspector of TA Tool Suite.
4- The measurements for the context switching is so far the most complicated to trace for me. I have seen many different Api activated in different conditions e.g. EE_rq2stk_exchange, EE_oo_run_next_task, EE_std_change_context, EE_tc_task_save, EE_tc_stack_restore, etc. For my application case would have been the best if I could trace and measure separately in a triple the context save, rescheduling and context load during a preemption due to higher priority task/ISR or due to context switching when the schedule() is called. What are the exact context switching APIs I should measure and what are the specific scenario calls of them?

Thank you in advance! Apologizes for so many questions and long post:).

Looking forward to your reply.

Kind Regards,
Erjola Lalo

paolo.gai
Administrator
Posts: 875
Joined: Thu Dec 07, 2006 12:11 pm

Re: Measuring Erika OS Api runtime

Post by paolo.gai » Tue Mar 22, 2016 6:01 pm

Hi!

Thanks for your e-mail, and say Hello to Felix, I talked to him recently at Embedded World!

I have some answers and some questions... I write them while reading your e-mail:

- We published some benchmarks of ERIKA on the wiki. If you are doing some measurements, please update the wiki with some fresh data :-) ... that will be useful for everybody

- some of the benchmarks have been taken using a simple applications that reads timers... you may want to look at it... It is on the SVN but I do not remember where ;-)

- Q1) I guess with cooperative scheduling you mean non-preemptive with scheduling point. Then you have to set up the tasks as non preemptive. If you want something mroe like the "grouping" performed in the Saksena & Wang paper in 2000, then you have 2 ways: use the internal resources (both tasks should share the internal resource), or for a fine grained setup, you will have to directly modify the dispatch priorities in the eecfg.c. In any case if not sure always check the dispatch priorities created by rt.druid

- Q2) GetResource/ReleaseResource, or the equivalent spinlocks specified by AUTOSAR (check the Tricore examples, there should be at least one with spinlocks)

- Q3) the system call is present only on tricore when you enable memory protection and you call primitives from non-rusted. otherwise is disable/enable irqs...

- Q4) the answer is quite long... so I will skip it (I know this recalls a famous Fermat proof but that is...). Basically in many situations the context switch is optimized (especially when you do not change tasks). Once upon a time the primitives where two, ready2stacked and stkchange. With the refactoring done by Errico there are a bit more names but their behavior should be straightforward. ERIKA v3 will be simpler in that respect (please comment the PDF we published if you have time!). In general I'm not sure if it makes sense to just measure the context swith, of whether it makes sense to measure the whole primitive.

Ciao,

PJ

Post Reply