[LITMUS^RT] recording start real-time task

[Glenn Elliott]

On Apr 22, 2014, at 12:05 PM, Mac Mollison <mollison at cs.unc.edu> wrote:

> I can't answer your specific question, but I do want to raise a separate
> issue.
> 
> I am the former maintainer of unit-trace and stopped maintaining
> it when I switched to working on a non-Litmus project.
> 
> My understanding is that there are now better tools available to do the
> same thing that actually are being maintained. Perhaps someone in the
> know can comment on these tools and their availability? I thought there
> was some tool that uses KernelShark.
> 
> In fact, I see some relevant code here, though I couldn't find any
> documentation about this on the LITMUS wiki:
> https://github.com/LITMUS-RT/rt-kernelshark
> 
> If that is not a good option for some reason, perhaps we should look at
> reviving unit-trace. Since it appers to have users who are suffering
> from its lack of maintenance.
> 
> Another (probably better) option would be to just make a new tool.
> 
> I have found that visualizing scheduler traces by creating an SVG file
> (which has HTML-like syntax) makes writing these tools trivial in
> comparison to the way we did it for unit-trace.
> 
> I have such a tool for my userspace work and forking it to draw LITMUS
> schedules would be a very easy project for someone who understands
> the LITMUS trace format. The code is all in Python and it's only 379
> lines.
> 
> - Mac
> 
> On Tue, 22 Apr 2014 16:50:48 +0200
> Thijs Raets <thijsraets at gmail.com> wrote:
> 
>> Hi,
>> 
>> The sys_release wasn't recognized by unit trace, I had to add the
>> sys_release type a second time in the array of the unit-trace script
>> since the type number was 11. I can record the task set release now
>> but I have a new problem now. This is my output:
>> 
>> 
>> .
>> .
>> .
>> 
>> Event ID: 7
>> Job: 0.0
>> Type: sys_release2
>> Time: 672784686695748
>> 
>> Event ID: 8
>> Job: 6904.1
>> Type: resume
>> Time: 672784686702656
>> 
>> Event ID: 9
>> Job: 6904.2
>> Type: release
>> Time: 672784686705186
>> 
>> Event ID: 10
>> Job: 6904.2
>> Type: switch_to
>> Time: 672784686727392
>> 
>> Event ID: 11
>> Job: 6904.3
>> Type: switch_away
>> Time: 672784686731107
>> 
>> Event ID: 12
>> Job: 6904.3
>> Type: completion
>> Time: 672784686736223
>> 
>> Event ID: 13
>> Job: 6904.4
>> Type: release
>> Time: 672785686000000
>> 
>> Rtspin has a period of 100ms. The resume of job 1 is ignored I only
>> look at release and completion. Job 2 is released but had no
>> completion(no worries I want soft real-time results). Job 3 only has
>> completion time. The real problem for me is the time difference
>> between the release of job 4 and job 2. It's nowhere near 200ms the
>> other jobs are released just fine, but they are all shifted because
>> of job 4 releasing late.(This problem only occurs when using
>> synchronous release)
>> 
>> Any ideas?
>> 
>> Thanks,
>> Thijs
>> 
>> 
>> 
>> 
>> 2014-04-17 12:48 GMT+02:00 Thijs Raets <thijsraets at gmail.com>:
>> 
>>> Hi,
>>> 
>>> That was exactly what I was looking for thank you! Is it possible
>>> that this sys_release event appears as type "resume" in my
>>> unit-trace output?
>>> 
>>> Kind regards,
>>> Thijs
>>> 
>>> 
>>> 2014-04-17 0:15 GMT+02:00 Glenn Elliott <gelliott at cs.unc.edu>:
>>> 
>>> Hi Thijs,
>>>> 
>>>> Are you using synchronous releases?  (The ‘-w’ option for
>>>> rtspin.)  With ‘-w’, rtspin will block until the user execute’s
>>>> liblitmus’s ‘release_ts’ (“release task set”).  Task set release
>>>> records a timestamped ’sys_release’ event in sched_trace.  You can
>>>> then discard any releases/completions that occur before the
>>>> sys_release timestamp.  I believe this will happen naturally if
>>>> you tell unit-trace to discard the first job of every task with
>>>> “-s 1”.
>>>> 
>>>> The “experiment-scripts” package (
>>>> https://github.com/LITMUS-RT/experiment-scripts) can also be used
>>>> to analyze traces.  However, it also requires you to use its
>>>> framework to set up experiments (this can take some time if you
>>>> need to do something out of the ordinary).  The tool currently
>>>> only gives you information on job deadline misses, tardiness, and
>>>> the amount of time tasks send blocked. However, it’s fairly easy
>>>> to extend parse/sched.py to do other forms of analysis, such as
>>>> job response time.
>>>> 
>>>> -Glenn
>>>> 
>>>> 
>>>> On Apr 16, 2014, at 12:14 PM, Thijs Raets <thijsraets at gmail.com>
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I'm using feather trace to monitor the rtspin task. I parsed
>>>> the .bin file with unit-trace and thus extracted release and
>>>> completion. The problem is that I also would like to record the
>>>> time at which I give the order to execute the rtspin task. I need
>>>> this time to calculate the theoretical deadlines of the different
>>>> jobs since the release time of the first job could have been
>>>> postponed. I however do not know how time is registered within
>>>> feather trace. I would like to use the same reference to record
>>>> the start time. Where do I look?
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> Thijs



Adding more to what Mac has said, rt-kernelshark is good for visualizing traces.  kernelshark is a tool designed for Linux that we extend for visualizing Litmus traces.  Owing to it’s Linux support, rt-kernelshark can give you a lot more information on what is going on within the Linux kernel than unit-trace’s visualization tool.