Hmm... The overhead costs obtained from ft_tools are not 100% exact because of the unpredictabilities of the system, but at least the approach doesn't depend on scheduling decisions, right? What I was trying to do is much less reliable.<br>
<br>Andrea recommended me to read these papers, because I don't know yet how to use ft_tools information.<br><br>U. Devi. Soft Real-Time Scheduling on Multiprocessors. PhD thesis,<br>
University of North Carolina, Chapel Hill, North Carolina, 2006.<br>
<br>
B. Brandenburg, H. Leontyev, and J. Anderson. Accounting for in-<br>
terrupts in multiprocessor real-time systems. In Proc. of the 15th<br>
IEEE Int’l Conf. on Embedded and Real-Time Computing Sys. and<br>
Apps., pp. 273–283, 2009.<br><br>If I have questions, I'll ask here.<br>Thanks!<br><br>Felipe<br><br><div class="gmail_quote">2012/2/17 Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Feb 17, 2012, at 6:03 PM, Felipe Cerqueira wrote:<br>
><br>
> Litmus-RT papers usually include schedulability comparisons that use schedulability tests and tasks inflated with overhead costs.<br>
> Is it possible to check schedulability by actually running the tasks?<br>
><br>
> I've been trying to modify rtspin to do that, but I'm facing some problems.<br>
><br>
</div>> […]<br>
<div class="im">> Has anyone already done schedulability checking inside the application? I thought it would be easier to do than embedding overhead costs within the tasks.<br>
> In case it is a bad approach, I can try the usual way.<br>
<br>
<br>
</div>I think your approach fundamentally doesn't work. Schedulability is an analytical property. A task set is schedulable if it can be shown that it won't miss a deadline (in the hard real-time case) for *any* legal arrival sequence. Observing whether deadlines are missed in the task can only establish that it is *not* schedulable, but not the inverse.<br>

<br>
By the way, rtpsin spins for approximately 90% of its configured WCET because the delay loop isn't exact. It may overshoot a little; hence setting the delay to 100% leads to the problems that you've described.<br>

<br>
- Björn<br>
<br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</blockquote></div><br>