Hi,
I was wondering what is the best practice for image streaming over a Gigabit Ethernet link. In my application, I have an ARM Cortex-A8 board simultaneously grabbing images (image resolution is 752x480 and image size is 353 KB) at 15 Hz from 4 cameras. This board publishes these images over UDP with RTI DDS. The image transmission requires a sustained bandwidth of 20.7 MB/s.
A series of processes takes the images as input, and compute controller commands at the end. These commands are used to control an UAV. Hence, any single high image latency may lead to instability in flight of the UAV. Thus, applications on the receiving end have the requirement that latency should be as low as possible, and as consistent as possible.
What is the best way to achieve consistent and low latency for transmission of large data packets? Do we use a publisher with a queue size of 1, or do we use a flow controller, or so on? If a flow controller is recommended, how should the parameters of the flow controller be configured?
Best regards,
Lionel
Hello Lionel,
We have an example of sending large data over DDS that could be very useful to you based on your question. Please take a look at :
http://www.rti.com/examples
Near the bottom of the page you will find a Use Case for "Sending Large Data". Inside there, you will find several options of a QoS profile that can be used to achieve sending large data at different latencies.
Bert
Hi Lionel,
I would like to add some technical information about the flow controller. The flow controller is modeled as a token bucket. You can choose the value of some parameters such as the maximum number of tokens you can store in the bucket, the number of tokens to be added and removed per period, the amount of bytes each token represents and the period to apply previous explained parameters. You can find these parameters in the table 6.71 in the User´s Manual:
DDS_Long max_tokens: Maximum number of tokens than can accumulate in the token bucket.
DDS_Long tokens_added_per_period: The number of tokens added to the token bucket per specified period.
DDS_Long tokens_leaked_per_period: The number of tokens removed from the token bucket per specified period.
DDS_Duration_t period: Period for adding tokens to and removing tokens from the bucket.
DDS_Long bytes_per_token: Maximum number of bytes allowed to send for each token available.
You can use these parameters to design your custom flow controller:
1) If you have to send periodic data at 15 Hz, you can set the period to be 1/15 sec.
2) If you have to send images of 353kB, you can set the token added per period to 6 and bytes per token to 60 kB (note that it is set in bytes). This way, every image will be sent as 6 UDP packets of 60 kB each one in the wire. If you prefer to send smaller packets, you can set it to 12 * 30 kB, etc. This way you control how is the data put in the wire.
3) I would set tokens leaked per period to zero.
4) I would choose the value of max tokens depending on your needs.
Note that although one token represents "bytes per token" bytes, each destination requires a different token, and every transport enabled requires a different token too... This way, my suggestion is to set the transport_builtin.mask in the participant qos to UDPv4 only (if you are using UDPv4) and multiply the number of tokens explained above by the number of destinations to receive the data. This way, if you are not using SHMEM, as it is set by default along with UDPv4, it won't affect your design.
Although I tried to be as detailed as possible, I know this information might not cover all your questions about this topic. Keep posting here your questions and giving us feedback.
Thanks for using the RTI Community Forum.
Best regards,
Juanjo Martin