Tools and Benchmarks for Real-Time Systems

Update October 2nd 2019: Amalthea model of the challenge has been replaced with a fixed version, where no overload situation occurs.

I am happy to announce the Amalthea model describing the application presented in the Industrial Challenge 2019. Please read the description for details about the application and the modelling concepts. We also provide a small Amalthea example model (CPU_Mapping_Changes) illustrating the transformations involved when moving a task from the GPU to a CPU.

Hi
I noticed that some tasks allocations have scheduler and affinities are not match.
For example Task CANbus_polling:
- affinity = processing unit core0 (Denver core)
- scheduler = Task scheduler A57
Is that a mistake or does it have any specific meaning?
Also, there are tasks (PRE_SFM_gpu_POST and PRE_Localization_gpu_POST) that have 2 affinities ( Processing Unit Core0, Processing Unit Core1). Would you mind clarify why does it has 2 affinity?

zero212 wrote: ↑

Tue Apr 02, 2019

Hi
I noticed that some tasks allocations have scheduler and affinities are not match.
For example Task CANbus_polling:
- affinity = processing unit core0 (Denver core)
- scheduler = Task scheduler A57
Is that a mistake or does it have any specific meaning?
Also, there are tasks (PRE_SFM_gpu_POST and PRE_Localization_gpu_POST) that have 2 affinities ( Processing Unit Core0, Processing Unit Core1). Would you mind clarify why does it has 2 affinity?

Hi,

in general you're right that the affinities and the scheduler have to match!
The provided mapping is invalid and it is part of the challenge to come up with a reasonable mapping.

The affinities of a task have to be a subset of the cores of which the scheduler is responsible for, otherwise the mapping is invalid.
In case a task has an affinity of just one core the core has to run on this core even if the scheduler is responsible for multiple cores.
In case a task has multiple affinities to different cores the scheduler can schedule the task to one of the cores (this leaves the scheduler the possibility to migrate the task during runtime).

In the challenge you are free to change the task mapping (task-Scheduler) + (task-Affinity).

In case you have more questions or find any other points regarding the model which are not clear, do not hesitate to ask.

Hi
thank you for the model! We're now trying to understand all the details.
I noticed that there are pre/post-processing runnables for the tasks mapped to the GPU that feature additional ticks. My questions are:

Where do those ticks come from?
When trying to solve the mapping challenge, are only those four tasks allowed to run on the GPU? There is neither information about ticks for the GPU on the other tasks nor information about pre/post-processing ticks.

Thanks for your help.

zero212 wrote: ↑

Wed Apr 03, 2019

Hi
thank you for the model! We're now trying to understand all the details.
I noticed that there are pre/post-processing runnables for the tasks mapped to the GPU that feature additional ticks. My questions are:

Where do those ticks come from?

Those ticks come from opencv functions, for instance let us suppose the case of the object detection task,
in the pre-processing phase the image is resized and cropped while in the post-processing phase bounding box are drawn.
It is impressive but in some cases (not in the model presented), these opencv functions take more than the execution time of the kernel in the GPU.

zero212 wrote: ↑

Wed Apr 03, 2019

When trying to solve the mapping challenge, are only those four tasks allowed to run on the GPU? There is neither information about ticks for the GPU on the other tasks nor information about pre/post-processing ticks.
Thanks for your help.

Yes it is, the other tasks are not parallelizable so porting them on the CPU will considerably hurt performance.
Also on the other hand, not all the GPU task can be mapped to the CPU (e.g detection): this is because even if you are theoretically able to have a big neural network running a CPU, it will take in the order of seconds to execute.

Nacho & Nicola

Nacho_S wrote: ↑

Thu Apr 04, 2019

zero212 wrote: ↑

Wed Apr 03, 2019

Hi
thank you for the model! We're now trying to understand all the details.
I noticed that there are pre/post-processing runnables for the tasks mapped to the GPU that feature additional ticks. My questions are:

Where do those ticks come from?

Those ticks come from opencv functions, for instance let us suppose the case of the object detection task,
in the pre-processing phase the image is resized and cropped while in the post-processing phase bounding box are drawn.
It is impressive but in some cases (not in the model presented), these opencv functions take more than the execution time of the kernel in the GPU.

zero212 wrote: ↑

Wed Apr 03, 2019

When trying to solve the mapping challenge, are only those four tasks allowed to run on the GPU? There is neither information about ticks for the GPU on the other tasks nor information about pre/post-processing ticks.
Thanks for your help.

Yes it is, the other tasks are not parallelizable so porting them on the CPU will considerably hurt performance.
Also on the other hand, not all the GPU task can be mapped to the CPU (e.g detection): this is because even if you are theoretically able to have a big neural network running a CPU, it will take in the order of seconds to execute.

Nacho & Nicola

One additional point to your question. The pre/post processing runnables are only necessary in case the tasks are mapped to the GPU. Therefore we decided to provide a model where all tasks (which are somehow parallelizable) are mapped to the GPU to provide all the necessary information. In case one of the GPU tasks should be mapped to a CPU core you can check the second provided model (CPU_Mapping_Changes) as an example. In general the possible mapping targets are implicitly specified by to the tick values for the different targets (A57, Denver, and GPU) or check figure 6 in the provided document (green GPU, teal CPU (Denver, A57)). However in case of remapping a task from the GPU to a CPU the pre- and post-processing tasks are needless. The Transformation from a GPU Task Mapping to a CPU Task Mapping is described in the appendix of the provided document.

arne.hamann wrote: ↑

Mon Mar 25, 2019

I am happy to announce the Amalthea model describing the application presented in the Industrial Challenge 2019. Please read the description for details about the application and the modelling concepts. We also provide a small Amalthea example model (CPU_Mapping_Changes) illustrating the transformations involved when moving a task from the GPU to a CPU.

The task "Planner" is activated every 12 ms but its execution time is higher than 12 ms for the A57 and the Denver.
Therefore please change the period of the task (stimuli in the Amalthea model) to 15ms.

Falk wrote: ↑

Thu Aug 29, 2019

arne.hamann wrote: ↑

Mon Mar 25, 2019

I am happy to announce the Amalthea model describing the application presented in the Industrial Challenge 2019. Please read the description for details about the application and the modelling concepts. We also provide a small Amalthea example model (CPU_Mapping_Changes) illustrating the transformations involved when moving a task from the GPU to a CPU.

The task "Planner" is activated every 12 ms but its execution time is higher than 12 ms for the A57 and the Denver.
Therefore please change the period of the task (stimuli in the Amalthea model) to 15ms.

I uploaded a model that incorporates this fix (top of the page).