OpenAMP's performance

[JjchenGravityxr]

I use echo_test to test between A53 and R5. The [Sending time] is fast (<200us). The [Receiving time] is slow (about 4500us). I don't know what went wrong. I want to know about the [Receiving time].

LOG is as follows:

Echo test start

Master>probe rpmsg_char

• lsmod Module Size Used by rpmsg_char 16384 0 virtio_rpmsg_bus 20480 0 rpmsg_ns 16384 1 virtio_rpmsg_bus rpmsg_core 16384 3 virtio_rpmsg_bus,rpmsg_char,rpmsg_ns zynqmp_r5_remoteproc 16384 0 mali 229376 0 xilinx_vfmc 28672 0 phy_xilinx_vphy 77824 4 uio_pdrv_genirq 16384 0 dmaproxy 16384 0

• modprobe rpmsg_char lookup_channel():232 using dev file: virtio0.rpmsg-openamp-demo-channel.-1.1024 bind_rpmsg_chrdev():128 open /sys/bus/rpmsg/devices/virtio0.rpmsg-openamp-demo-channel.-1.1024/driver_override bind_rpmsg_chrdev():151 write virtio0.rpmsg-openamp-demo-channel.-1.1024 to /sys/bus/rpmsg/drivers/rpmsg_chrdev/bind get_rpmsg_chrdev_fd():171 opendir /sys/bus/rpmsg/devices/virtio0.rpmsg-openamp-demo-channel.-1.1024/rpmsg get_rpmsg_chrdev_fd():181 open /dev/rpmsg_ctrl1 main():307 rpmsg_create_ept: rpmsg-openamp-demo-channel[src=0,dst=0x400] checking /sys/class/rpmsg/rpmsg_ctrl1/rpmsg0/name svc_name: rpmsg-openamp-demo-channel . open /dev/rpmsg0

  Echo Test Round 0

  sending payload number 0 of size 17 [Sending time use:184]echo test: sent : 17 [Receiving time use:574]received payload number 0 of size 17

  sending payload number 1 of size 18 [Sending time use:114]echo test: sent : 18 [Receiving time use:4472]received payload number 1 of size 18

  sending payload number 2 of size 19 [Sending time use:114]echo test: sent : 19 [Receiving time use:4465]received payload number 2 of size 19

  sending payload number 3 of size 20 [Sending time use:110]echo test: sent : 20 [Receiving time use:4437]received payload number 3 of size 20

  sending payload number 4 of size 21 [Sending time use:110]echo test: sent : 21 [Receiving time use:4465]received payload number 4 of size 21

  sending payload number 5 of size 22 [Sending time use:115]echo test: sent : 22 [Receiving time use:4466]received payload number 5 of size 22

  sending payload number 6 of size 23 [Sending time use:117]echo test: sent : 23 [Receiving time use:4466]received payload number 6 of size 23

  sending payload number 7 of size 24 [Sending time use:111]echo test: sent : 24 [Receiving time use:4466]received payload number 7 of size 24

  sending payload number 8 of size 25 [Sending time use:111]echo test: sent : 25 [Receiving time use:4472]received payload number 8 of size 25

  sending payload number 9 of size 26 [Sending time use:110]echo test: sent : 26 [Receiving time use:4485]received payload number 9 of size 26

  sending payload number 10 of size 27 [Sending time use:110]echo test: sent : 27 [Receiving time use:4461]received payload number 10 of size 27

  sending payload number 11 of size 28 [Sending time use:115]echo test: sent : 28 [Receiving time use:4469]received payload number 11 of size 28

  sending payload number 12 of size 29 [Sending time use:118]echo test: sent : 29 [Receiving time use:4471]received payload number 12 of size 29

  sending payload number 13 of size 30 [Sending time use:114]echo test: sent : 30 [Receiving time use:4470]received payload number 13 of size 30

[arnopo]

Could you detail the HW platform and Software versions used?

[JjchenGravityxr]

Could you detail the HW platform and Software versions used?

HW platform： Xilinx Zynq UltraScale+ MPSoC ZCU106

software： xilinx VCU TRD 2022.1 petalinx 2022.1 kernel: xlnx_rebase_v5.15_LTS_2022.1 (quad A53 SMP) Freertos:10.0 (Dual R5 AMP)

[arnopo]

@TanmayShah-xilinx , @bentheredonethat Any clues?

[Raveem13]

Hi @arnopo, The issue still exists or is it resolved in the latest version?

[tnmysh]

I am not sure how the receiving time is measured. I have not get chance to work on this.

One logical explanation I can think of is, APU runs at higher speed than RPU. So, If receiving time is measured on APU then it is expected that rx time is more than tx time. As RPU is slower than APU, it takes more time to process and send data than APU.

In this case, I wouldn't consider this as issue but expected behavior.

The correct way to measure send/receive time would be to run same algorithm on both RPUs running at same speed in split mode and then measure send and receive time.

[tnmysh]

@JjchenGravityxr @arnopo I don't think anything is wrong with what was measured w.r.t. send/recv time.

I don't think we should consider this an issure, as send time and recv time depends on core frequency. As explained above send time is less as APU runs on x GHz and recv time is more as RPU runs on y MHz frequency. So it is expected that recv time is more than send time.

If you agree to this analysis can we close this issue?

Tanmay.

[arnopo]

@JjchenGravityxr @arnopo I don't think anything is wrong with what was measured w.r.t. send/recv time.

I don't think we should consider this an issure, as send time and recv time depends on core frequency. As explained above send time is less as APU runs on x GHz and recv time is more as RPU runs on y MHz frequency. So it is expected that recv time is more than send time.

If you agree to this analysis can we close this issue?

Tanmay.

I close it. this point is not related to the library but the platform. A discussion can be open if need to go further