TDA4AL-Q1: [TDA4AL] IPC userspace performace question

Hi,

Assigned engineer is out of office, kindly expect delay in response.

Regards,

Manojna

Hello,

Can you please check https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/10_01_00_04/exports/docs/pdk_jacinto_10_01_00_25/docs/datasheet/jacinto/datasheet_j721e.html ?

The IPC remains same for all the J7 devices. You can refer the IPC performance numbers from the above link.

This is round about time of "Hello world" from rpmsg_char_simple example sent to R5F core and returned back to A72.

You can optimize it by writing better example on both the ends.

Regards

Tarun Mukesh

Hi Tarun Mukesh:

      Below table picture, I have some question:

     1. What the measure unit? Is ms(millisecond) or us(microsecond)?

      2. What's that Hose core A72? Is it that mean A72 send echo to each other core (MCU R5F0 or Main R5F0 or C66x1 etc) and back to A72 time? Is test store from A72 to other core round trip time, right?

      3. What's mean different data size? And Why different size have different performance? Is it cause by memory copy?

      4. From my test log shown "round trip delay(usecs) = 102675", It's 102ms, right? And I think that's bad performance!

Hi Tarun Mukesh:

      One more question that what's Bios? Is that mean A72 run Linux SDK?

Hello,

Sheng-Shun Chang said:

   1. What the measure unit? Is ms(millisecond) or us(microsecond)?

It is already mentioned in the link it is us.

Sheng-Shun Chang said:

2. What's that Hose core A72? Is it that mean A72 send echo to each other core (MCU R5F0 or Main R5F0 or C66x1 etc) and back to A72 time? Is test store from A72 to other core round trip time, right?

Host core A72 is A72 starting the data sent and echoing it back.

Sheng-Shun Chang said:

      3. What's mean different data size? And Why different size have different performance? Is it cause by memory copy?

Yes 

Sheng-Shun Chang said:

4. From my test log shown "round trip delay(usecs) = 102675", It's 102ms, right? And I think that's bad performance!

The performance numbers are based on bios not on linux. The data you are comparing bios with linux is not correct.

bios is basic os not linux or any kind of hlos.

Regards

Tarun Mukesh

Hi Tarun Mukesh:

      Thanks, your comment!

      If I want to improvement the round trip delay in linux OS. What can I do on rpmsg_char_simple? Reduce data size? any else ideal? Because the round trip time was too long! Or any other suggestion way?

Hello,

Let me check and get back to you.

Regards

Tarun Mukesh

Hello,

I checked linux code we are measuring the times right before the send call and after receive the message.

clock_gettime(CLOCK_MONOTONIC, &ts_current);
		ret = send_msg(rcdev->fd, (char *)packet_buf, packet_len);
		if (ret < 0) {
			printf("send_msg failed for iteration %d, ret = %d\n", i, ret);
			goto out;
		}
		if (ret != packet_len) {
			printf("bytes written does not match send request, ret = %d, packet_len = %d\n",
				i, ret);
		    goto out;
		}

		ret = recv_msg(rcdev->fd, 256, (char *)packet_buf, &packet_len);
		clock_gettime(CLOCK_MONOTONIC, &ts_end);
		if (ret < 0) {
			printf("recv_msg failed for iteration %d, ret = %d\n", i, ret);
			goto out;
		}

send_msg() from user space is calling kernel level API's is causing the delay in linux OS but we cannot avoid this in Linux OS side.

On other side R5F, As you are using MCU1_0 it has sciserver (mandatory task) as more priority than Ipc_echo_test this may cause a bit of delay if any context switch happened between tasks of ipc_echo_test and sciserver.

May be you can check with any other R5F core with only ipc_echo_test task and see any better numbers you get from it.

Regards

Tarun MUkesh

Hello,

For linux OS side there is nothing to modify much it is the time internally it takes.

Sheng-Shun Chang said:

Sending message #2845: hello there 2845!
Received message #2845: round trip delay(usecs) = 60140

Here you reach almost 60ms ,How much is your expectation ?

On R5F side, you can keep ipc as highest priority task to get better results. But as per MCU R5F you should have sciserver as highest priority rather than any other tasks,

RegardS

Tarun Mukesh

Hi Tarun Mukesh:

     Thanks your comment and suggestion!

     I expectation the IPC round trip delay should be average in 40ms(round trip delay). Can I do that?

     How can I measure the round-trip time from SOC to MCU, and how much time is spent on each segment? I would like to measure it to know where's take long time. For example userspace to kernel space take many time. How can I measure it?

Hi Tarun Mukesh:

      Correct my expectation performance.

      1. SOC to MCU must periodic send data in 40 ms. Data size 3000 bytes in one packet.

      2. MCU to SOC must periodic send data in 10 ms. Data size 200 bytes in one packet.

      As our target, SOC to MCU data size was 3000 bytes, but IPC max was 496 (512-16) bytes. As I know, it seem have another way that send share memory data address through IPC. Not send data through IPC. Do you have any example code for me reference?

Hi 

     I refer website software-dl.ti.com/.../developer_notes_ipc.html

• To reduce latencies and / or to send larger buffer it is recommended to pass a pointer/handle/offset to a larger shared memory from ION heap

      Does have any example?

Hello,

Sheng-Shun Chang said:

• To reduce latencies and / or to send larger buffer it is recommended to pass a pointer/handle/offset to a larger shared memory from ION heap

      Does have any example?

No we don't have any example in SDK that does this.

Sheng-Shun Chang said:

      As our target, SOC to MCU data size was 3000 bytes, but IPC max was 496 (512-16) bytes. As I know, it seem have another way that send share memory data address through IPC. Not send data through IPC. Do you have any example code for me reference?

No reference code.

Sheng-Shun Chang said:

 How can I measure the round-trip time from SOC to MCU, and how much time is spent on each segment? I would like to measure it to know where's take long time. For example userspace to kernel space take many time. How can I measure it?

How much time it is taking in kernel is very much into Linux OS . Usually this will not be much helpful since OS driver API's are not going change or modify.

Currently you are using ipc_echo_test on R5F core ,It is not optimized one and has prints which take long time , and have sciserver as highest priority .

In your custom R5F application, you need to keep ipc task as highest priority and optimize the code without any console prints and check the response time.

Do you have custom application written on R5F code ?

Regards

Tarun Mukesh

Hi Tarun Mukesh:

     I will try to look at ipc_echo_test if I can doing anything!

     I saw another case have taking about the rpmsg_char_zerocopy. It's seem can send larger data between remote core and SoC side. Does this also can apply on TDA4? Can I use this?

https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/ 

Hi Tarun Mukesh:

     Thanks your comment and feedback to me! I will close case first. Another question I will create new case. Many thanks you help!