AM6442: ipc_rpmsg_echo delay

Hi Fan, from documentation we have:

AM64x MCU+ SDK: Datasheet

I am checking if there is any code available or guidance on how this benchmark was calculated

thank you,

Paula

Hello,

Benchmark source code

I will be commenting from the perspective of a Linux developer. So don't be surprised, I will link you to some Linux code that I wrote.

The source code is only in the git repo, not in the processor specific SDK. Here:
https://github.com/TexasInstruments/mcupsdk-core/tree/next/test/drivers/ipc_notify 
https://github.com/TexasInstruments/mcupsdk-core/tree/next/test/drivers/ipc_rpmsg 

Please keep in mind that these test reports do not help with your concern, which is understanding worst-case latency over long (i.e., statistically significant) test runs. They just discuss average round-trip latency from 10,000 runs.

For Linux customers, I just published the rpmsg_char_benchmark application, which can be used to get an idea of RPMsg performance within a specific Linux system and the MCU+ cores:
* performance w/ sending any number of characters between 1 and 496
* average round trip latency, worst-case round trip latency, a histogram with the complete plot of behavior
* do any number of runs between 10 to 1 trillion (not actually suggested, a 1 trillion run would take more than a month to execute between Linux and an MCU+ core)

https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/tree/examples/README

sample output here:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1410313/am6442-communication-latency-issues-between-a53-and-r5-in-a-linux-rt-system/5434861#5434861

What about your MCU+ SDK only test results? 

There are some bugs in RPMsg IPC 9.2 that were fixed in later releases - the biggest one was that the RPMsg communication would lock up if the RX buffer filled all the way up (I think 16 RPMsg messages is the default size?). Since you are only sending 1 RPMsg at a time, I would not expect you to be running into that issue.

This clearly looks like a software bug or software behavior issue, rather than an IPC latency issue. Have you observed any patterns? e.g., do you always see the latency numbers go up after a certain number of messages have been sent?

Regards,

Nick

HI NIck
Thanks for providing the idea. I'm sending 1024 bytes each time, and I've set both my buffers and buffer size to the maximum: 16 buffers with a total size of 1152 bytes. The operation I'm doing now is that within a 1ms interrupt function, the A53_00 core loops to send 1024 bytes and times the operation, while the R10 core receives the data. The phenomenon I'm currently observing is that at the very beginning of the program start, the timing for sending a message is about 2-3 μs. However, within a few seconds, it suddenly increases to over 300,000 μs and then stays consistently at this high latency. I believe that when communication isn't fully established yet, messages go directly into the IPC buffers, hence the 2-3 μs timing. But when the buffers are exhausted, the latency jumps to around 300 ms.

Regards,

pingan

Hello Pingan,

Ahh, I missed that you were not doing round-trip latency to send an RPMsg, and then receive an RPMsg back.

I wonder if you are running into the "RPMsg locking up if the RX buffer is full" issue, or something similar. Code here:
RE: PROCESSOR-SDK-AM62X: Multicore development, IPC Process, Multiple Endpoints, Reserved memory purpose

Regards,

Nick