<div dir="ltr">Thanks, <span style="font-family:arial,sans-serif;font-size:13px">Björn. After changing from rtspin to </span>rt_launch, I could see that there are no missing records w/o changing anything.<div><br></div><div><br></div><div>I have 3 simple questions about the st_job_stats data. Any comments are welcome!</div><div><br></div><div><div>*** Example: 8*(Period, WCET)=8*(200,180)ms on 8 Cores (both bare-metal and VM cases) [8 "same" tasks using rt_launch]</div></div><div><br></div><div>Using st_job_stats, I could see [Task, Job, Period, Response, DL Miss?, Lateness, Tardiness] records. <br></div><div><br></div><div><br></div><div>(1) Some files describe right period (200ms) but some files describe 0 period as follows. Does it mean that PID#13162 is not schedulable and PID#13166 is only schedulable? But, the Lateness/DL_Miss? of PID#13162 shows no deadline missing.</div><div><br></div><div><div># task NAME=<unknown> PID=13162 COST=0 PERIOD=0 CPU=-1</div><div> 13162, 2, 0, 180031469, 0, -19968531, 0</div><div> 13162, 3, 0, 180026058, 0, -19973942, 0</div><div> 13162, 4, 0, 180029476, 0, -19970524, 0</div><div> 13162, 5, 0, 180027542, 0, -19972458, 0</div><div>....</div><div><br></div><div><div># task NAME=rt_launch PID=13166 COST=180000000 PERIOD=200000000 CPU=0</div><div> 13166, 2, 200000000, 180019319, 0, -19980681, 0</div><div> 13166, 3, 200000000, 180022003, 0, -19977997, 0</div><div> 13166, 4, 200000000, 180022586, 0, -19977414, 0</div><div> 13166, 5, 200000000, 180021609, 0, -19978391, 0</div></div><div><br></div><div><br></div><div>(2) When I checked the total lines (total number of jobs) for each PID, each task has the exactly same number of jobs in some cases, but sometimes the number of jobs is slightly different among 8 tasks as follows. Is this expected or not? There is no missed record among total lines. Some tasks have 1 or 2 more jobs. Is it possible?</div><div><br></div><div>116 116 115 115 114 115 114 114<br></div><div><br></div><div><br></div><div>(3) I want to repeat test-case 20 times and then average their schedulability. In either case (whether including period=0 jobs are included to scheduled job or not), I could see that inter-run variation happened a lot as follows. Is this expected or not? Can you get consistent traced records (consistent fraction of schedulable task sets) any time??</div><div> </div><div>1.00 1.00 1.00 1.00 1.00 .13 1.00 1.00 1.00 .13 .13 1.00 .25 .13 .13 .13 .13 1.00 .25 1.00 <br></div><div><br></div><div><div><div>Could you please comment for those 3 questions or even 1?</div><div>Thanks for your help in advance!</div><div><br></div><div>Mikyung</div></div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 4:21 AM, Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 18 Sep 2014, at 06:29, Mikyung Kang <<a href="mailto:mkkang01@gmail.com">mkkang01@gmail.com</a>> wrote:<br>
><br>
> I'm trying to get whole tracing information of RT task sets using LITMUS-RT Version 2014.1.<br>
><br>
> * System has 8 Cores, no hyper-threading, 16G memory<br>
> * Tested both Bare-metal case and Virtualization case (Xen): similar result<br>
> * Ubuntu 12.04 (Linux 3.10.5)<br>
> * Generated 10 tasks w/ Utilization=[1.0, 8.0] using rtspin<br>
> * Run 10 seconds using GSN-EDF scheduler<br>
><br>
> When I spawned only 1 task (Period=100ms, WCET=10ms) during 10 seconds, all records are being saved into .bin file correctly w/o missing records.<br>
> But, more than 1 task, always records are being missed a lot.<br>
<br>
</span>This sounds like something is broken. Even with 8x(10, 100) tasks you should have no tracing problems at all as there should be more than enough time for st_trace to catch up. Your system must be overutilized somehow.<br>
<span class=""><br>
><br>
> To avoid record-loss, I tried the following options based on the thread: <a href="https://lists.litmus-rt.org/pipermail/litmus-dev/2013/000480.html" target="_blank">https://lists.litmus-rt.org/pipermail/litmus-dev/2013/000480.html</a>.<br>
><br>
> * Kernel config: CONFIG_SCHED_TASK_TRACE_SHIFT=13 (up to 8K events)<br>
> * Used /dev/shm/* instead of disk for the binary record file<br>
> * Removed unnecessary events for the calculation of deadline miss ratio (switch_to/from, block, resume, action, np_enter/exit)<br>
> * Current KERNEL_IMAGE_SIZE 512*1024*1024<br>
><br>
> Then, around 4K events are being saved into one task-assigned core (st-*.bin).<br>
> When I got the information through st_job_stats, I could see that the number of recorded events per task is very different even though tasks have the same period.<br>
> Moreover, usually 5~20% records are being missed for each task set, even though utilization is very low. Sometimes, more than that.<br>
<br>
</span>This indicates that your system suffers from intervals of overload during which the tracing tools are starved. Are you sure this happens already with only two tasks?<br>
<span class=""><br>
><br>
> Is this expected record-loss ratio using st_trace tool?<br>
<br>
</span>No, unless the st_trace tool is being starved there should be no records lost.<br>
<span class=""><br>
> What should I check more? Is there any other way to reduce/remove record-loss?<br>
<br>
</span>You can try editing litmus/Kconfig to raise the limit for CONFIG_SCHED_TASK_TRACE_SHIFT. You can also try running st_trace as a real-time task (with rt_launch).<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></div>