[LITMUS^RT] Question about GSN-EDF in Litmus

[Luo, Zheng]

Thank you very much for the reply. That is very helpful. In the email, you mentioned that I can also use Litmus's sched_trace logs to get more accurate information on job release times, completion times, and many other events. I was wondering where that program is?


Is it the program in the folder ft_tools, named st_trace? It seems that I can not get the data properly from it.


Also, is there any good documentation of Litmus? I sometimes feel very hard to figure out the function of each program.


Thank you very much. Looking forward to your reply.


Zheng Luo


________________________________
From: litmus-dev-bounces at lists.litmus-rt.org <litmus-dev-bounces at lists.litmus-rt.org> on behalf of Glenn Elliott <gelliott at cs.unc.edu>
Sent: Saturday, November 16, 2013 8:09 AM
To: litmus-dev at lists.litmus-rt.org
Subject: Re: [LITMUS^RT] Question about GSN-EDF in Litmus

Hi Zheng,

The general structure of a typical litmus application looks like this:

init_litmus(); /* initialize litmus (basically just pins the programs memory to avoid page faults) */
set_rt_task_param();  /* set task params, such as period, relative deadline, execution time, etc. */
task_mode(LITMUS_RT_TASK); /* become a real-time task */
wait_for_ts_release(); /* wait for synchronous task set release-i.e., until liblitmus's release_ts program is run */
while(running) { /* keep executing jobs until task should exit */
   do_work();  /* do the actual work of a job */
   sleep_next_period();  /* sleep until next job release */
}
task_mode(BACKGROUND_TASK); /* exit real-time mode */
exit(0);

You can take a look at liblitmus/bin/rtspin.c and liblitmus/bin/base_task.c for examples.  (Note: Use of wait_for_ts_release() is optional.  However, without it, you may want to swap the order of sleep_next_period() and do_work().)

The structure of your program is incorrect:

init_litmus();
set_rt_task_param();
task_mode(LITMUS_RT_TASK);
task_mode(BACKGROUND_TASK);
job();

Problems:
1) job() is not in a loop.  (This would only be correct if you were doing real-time job shop scheduling.)
2) job() should be between task_mode(LITMUS_RT_TASK) and task_mode(BACKGROUND_TASK).  You only need to call task_mode(LITMUS_RT_TASK) once per task, not once per job.

One last comment: It looks like you are reading the time stamp counter to trace start and finish times.  This is fine in the correct context, but you can also use Litmus's sched_trace logs to get more accurate information on job release times, completion times, and many other events.  In general, you have to be careful measuring times in userspace.  For instance, you cannot measure job release times in userspace because a job may not be immediately scheduled when it is released (there might be higher-priority work that needs to be scheduled first).  Thus, a userspace release measurement would have an error of (time the job was first scheduled - true release time).  It's best if you use sched_trace logs to get accurate data.

-Glenn


On Nov 16, 2013, at 2:37 AM, Luo, Zheng <luozheng at wustl.edu<mailto:luozheng at wustl.edu>> wrote:

Hi All,

I am a master's student in Washington University who is doing research on realtime system. I installed Litmus because it has the global EDF scheduler. However when I do a simple experiment by using it. I simply can not get the right result. The EDF scheduler acts like a round robing scheduler. I don't know where I did wrong. The Litmus I installed is LITMUS-RT Version 2013.1.

I put my source code as a attachment, and also the screenshot of the result. Hope you can help me with. Thank you very much. Looking forward to your reply.

Zheng Luo
<Screenshot 2013-11-15 21:30:34.png><test_mt_task.c>_______________________________________________
litmus-dev mailing list
litmus-dev at lists.litmus-rt.org<mailto:litmus-dev at lists.litmus-rt.org>
https://lists.litmus-rt.org/listinfo/litmus-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20131118/77bc97d9/attachment.html>