Questions regarding the amalthea model

[rivasjm]

Hello all,

I am Juan M Rivas from the University of Cantabria. We are trying to solve the FMTV challenge, and we have came up with some questions. Maybe someone could help us.

- The first sub-challenge states that we have to ignore the memory accesses and arbitation. Does this mean that in each Runnable, we only have to consider the instructions executed in the processor, absolutely ignoring the memory cycles?

- Is the scheduler preemptive or non-preemptive?

- In the constraints model we don't understand EffectChain_1. Its stimulus is _149 and its response is _107, but this is not in accordance with its segments which are (_107 -> _243 -> _272 -> _107). Is this a mistake in the model? should it be (_149 -> _243 -> _272 -> _107) instead? Also, we don't quite understand the meaning of the Event Chain constraint, we haven't found a definition that fully explain its behavior. Does it impose a precedence relationship that must be met in the execution of the Runnables?


Thanks in advance, and good luck with the challenge!
Juan M. Rivas

[rivasjm]

We just noticed that some tasks are preemptive while other are cooperative (non-preemptive).

[Sophie Quinton]

Hi Juan,

I have contacted the Bosch people and hopefully they will answer very soon.

Best,
Sophie

[Simon Kramer]

Hello Juan,
please see my answers below.
Best,
Simon

Hello all,

I am Juan M Rivas from the University of Cantabria. We are trying to solve the FMTV challenge, and we have came up with some questions. Maybe someone could help us.

- The first sub-challenge states that we have to ignore the memory accesses and arbitation. Does this mean that in each Runnable, we only have to consider the instructions executed in the processor, absolutely ignoring the memory cycles?
Yes, that means that you can ignore them here. Take the execution time as given in the runnable.

- Is the scheduler preemptive or non-preemptive?
Scheduling is preemptive.

- In the constraints model we don't understand EffectChain_1. Its stimulus is _149 and its response is _107, but this is not in accordance with its segments which are (_107 -> _243 -> _272 -> _107). Is this a mistake in the model? should it be (_149 -> _243 -> _272 -> _107) instead? Also, we don't quite understand the meaning of the Event Chain constraint, we haven't found a definition that fully explain its behavior. Does it impose a precedence relationship that must be met in the execution of the Runnables?
There's a bug in the model. Thanks for the hint. The overall chain is from _149 to _107. Its segments should be _149 to _243, _243 to _ 272 and _272 to _107. We will upload an updated model shortly!
The meaning of an event chain constraint here is a precedence relation. All events in the segments have to traversed in that order.


Thanks in advance, and good luck with the challenge!
Juan M. Rivas

[rivasjm]

Thanks Simon for your answers, things are more clear now. Also thanks Sophie for contacting them,

We have started working with the model, and we came up with another problem, we are measuring utilizations above 100%. We are not sure if we are interpreting the model well or not.

For example, Task_1ms has a period of 1ms, which is 200000 cycles (considering a clock of 200 Mhz). Its fourth Runnable is Runnable_1ms_3, which has an upper bound for its number of instructions (ignoring labels) of 196224. If we consider 1 instruction/cycle, just this Runnable is almost overloading the processor in the worst case. If we add the rest of Runnables exexuted by Task_1ms, the upper bound of the number of instructions is above 2 million, which for a period of 200000 cycles, means this task has a utilization above 1000%. Is this interpretation instructions ok?

Thanks again in advance,
Best regards
Juan

[arne.hamann]

Dear Juan,

your interpretation is correct. We just checked the model, and found out that there was a mistake on our side. In principle, it is plausible that the system is overloaded if all worst-cases are considered simultaneously. However, in this case the numbers are far too high, such that already in the average case the system is overloaded. This should not be the case.

We will provide an updated model as soon as possible.

Best,
Arne

[arne.hamann]

We corrected the challenge model. You can find the updated version here: viewtopic.php?f=27&t=62&p=96#p96

[rivasjm]

We corrected the challenge model. You can find the updated version here: viewtopic.php?f=27&t=62&p=96#p96

Thank you for the new model. We now see that if we consider only worst-case execution times, the utilizations are now sligthly above 100%, which according to your previous answer is plausible. Also it seems that the priorities have been reversed, we assume that now it follows the "bigger number means more priority" criterion.

Best,