-
Notifications
You must be signed in to change notification settings - Fork 0
Fine tune the send and receive buffers
| Item | Value |
|---|---|
| Guideline Number | 44 |
| Guideline Responsible (Name, Affiliation) | Philippe Millet, Thales |
| Guideline Reviewer (Name, Affiliation) | Boitumelo Ruf, FHG |
| Guideline Audience (Category) | Application developers, System architects |
| Guideline Expertise (Category) | Application developers, System architects |
| Guideline Keywords (Category) | optimising the communication |
The send and receive buffers of the communication mediums must be sized for each application big enough to avoid the concertina effect but as small as possible to use as little memory resources as possible.
Concertina effects can occur when a data flow or a pipeline has to stop at some stage. Like in traffic jam, it will then propagate in the pipeline and reduce the performance of the whole system.
This effect arise mostly when a task in the pipeline has variability (either it needs a variable time to compute or it delivers a variable amount of data). This variability has to propagate in the system and will impact the neighbor tasks. To limit the impact of variability, input and output buffers are used to isolate one task from the behavior of the neighbors. The upstream neighbors will write their output buffers. A communication medium (most likely with a DMA) will transfer the data from that output buffer to the downstream neighbors' input buffers.
Recommended implementation method of the guideline along with a solid motivation for the recommendation
The basic implementation is to have a total of 4 buffers. 2 input buffers and 2 output buffers:
- One input buffer is used for the task to read data from, the other input buffer is used by the communication medium to write data in.
- One output buffer is used by the task to write the processed data, the other output buffer is used by the communication medium to read data from.
Having these buffers allows the processor to have two buffer reserved for its computation. It can freely work on the input data without locking the DMA that would have to wait for the processing to be finished before loading data again in the input buffer. This allows a simultaneous work of both the CPU and the DMA as they work on their own buffers. When the CPU has finished processing the data from the first input buffers, then it start processing the data from the second input buffer, while the DMA will load new data in the first input buffer.
But in a pipeline of tasks, the execution of each task might be different from the execution of the other tasks. And their execution time might also vary over time. Therefore it is necessary to adapt the number of buffers to a number that allows the whole application to overcome the concertina effect.
Since the required number of buffers strongly depends on the scheduling of the application, it must be given the application developer a mean to configure the number and the size of these buffers.
The operating system allows the user to configure the communication medium and to adjust the number of buffers. One way to allow the user to define the number of buffers that are necessary for his application is to provide the user with an API to allocate the buffers. Another method is to let the user allocate memory and only ask the user to provide the communication medium with the proper pointers to these buffers.
In Tulipp we selected the second way.
In the medical application we actually use 2 input buffers and 2 output buffers.
TULIPP Guideline Wiki