[LITMUS^RT] Unexpected worst case response time

[Björn Brandenburg]

> On 28 Mar 2017, at 12:14, 施俊杰 <shijunjie92 at gmail.com> wrote:
> 
> I got some unexpected results during my experiments when using the protocol under P-FP plugin. I used 'rtspin' to set the task, 'st-trace-schedule' to collect the data and 'st-job-stats' to handle the data. 

What does the schedule look like?

> I set my task as follows: WCET: 1ms, critical section: 0.5 ms, partition: cpu_0, resource location: cpu_1, protocol: DPCP, period: 2ms, total execution time: 100s.

Is this using rtspin?

> There is only one real-time task in my system. The result of the WCRT is 1.34 ms which is too large than the expected value.

What response time did you expect? Keep in mind that the task still needs to do some other work to prepare the next periodic release. 

> And if I set the protocol as MPCP, partition is cpu_0 (same as resource location), the WCRT is 1.125 ms, which is also too large. 

Again, what did you expect?

> Moreover, if I add the number of tasks to 40, the unexpected overheads of DPCP can be accumulated to more than 1 ms.
> Can any one explain that?

Can you trace the source of the overhead?


> Or do I need to modify my configuration?

Depends on what you have enabled… did you turn off all debugging options?

- Björn