[LITMUS^RT] recording start real-time task

[Björn Brandenburg]

On 22 Apr 2014, at 16:50, 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?

Hi Thijs,

a synchronous task system release advances the job counter.

	https://github.com/LITMUS-RT/litmus-rt/blob/master/litmus/jobs.c#L61

Waking up after a long suspension also advances the job counter, as the resuming task is considered to exhibit a sporadic job release. 

So the first couple of "jobs" typically correspond to the setup phase of the task set.

Looks like job 6904.4 is the first "real" (= post synchronous release) job.

If this is annoying to you, you could hack the kernel to reset the job counter to 0 on a synchronous task system release.

Regards,
Björn