[LITMUS^RT] recording start real-time task

Mac Mollison mollison at cs.unc.edu
Tue Apr 22 18:05:42 CEST 2014


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
> >> _______________________________________________
> >> litmus-dev mailing list
> >> litmus-dev at lists.litmus-rt.org
> >> https://lists.litmus-rt.org/listinfo/litmus-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> litmus-dev mailing list
> >> litmus-dev at lists.litmus-rt.org
> >> https://lists.litmus-rt.org/listinfo/litmus-dev
> >>
> >>
> >




More information about the litmus-dev mailing list