Hello there,
Is it possible to tell us the transfer delay time between A/B ports in HSR for AM6442?
Speed | 64 byte | 1518 byte |
1Gbps | ? | ? |
100Mbps | ? | ? |
Best regards,
Ryuto
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello there,
Is it possible to tell us the transfer delay time between A/B ports in HSR for AM6442?
Speed | 64 byte | 1518 byte |
1Gbps | ? | ? |
100Mbps | ? | ? |
Best regards,
Ryuto
Hello Ryuto,
Thanks for your question.
Can you please help us understand if this delay time measurement is in context of MCU PLUS SDK or the PROCESSOR SDK LINUX ?
Regards,
Vaibhav
Hello Vaibhav,
Either environment is acceptable.
For example, if a packet is transferred from PC -> PortA -> PortB -> PC, can you tell me the transfer time for PortA -> PortB?
Regards,
Ryuto
Hello Ryuto,
Please expect a delay in response to your inquiry from me until next week as I am attending all-day trainings this week. I will look into your inquiry once I'm back.
-Daolin
Hi Ryuto,
From a Linux perspective, without hardware offloading, the delay could be ~100's of us. With hardware offloading, the best case scenario is ~1.5us when there is no local traffic on the two ports from the A53 core. This can also be tested by sending an HSR frame in a network of 3 devices, from first device to third device and monitoring the delay between the two ports with and without hardware offloading with packet sniffer such as Profishark.
-Daolin
Hello Daolin,
Thank you for your reply.
Regarding the information you provided, what is the speed and packet size?
Also, you mentioned with and without offloading, what does this offloading indicate?
Regards,
Ryuto
Hi Ryuto,
The numbers I reported were estimated for a line rate of 1Gbps. I currently don't have an answer for the packet size that was used but I do know that the delay is not really dependent on the packet size unless the duration of receiving packets is less than the minimum cut-through frequency of ~1.5us. One thing to take note of is that short packets at line rate can come in at a much higher rate than the min cut-through frequency. For instance, a 64B frame size at 1Gbps line rate would mean about 1 frame every ~512ns to 672ns which is much less than ~1.5us. When the duration of receiving packets is less than min cut-through frequency, then the packet transfer from port-to-port would become "store-and-forward" switching which can add delay.
Without hardware offloading means that port-to-port forwarding and TX packet duplication is handled in software by the HSR driver in the Linux kernel, which can add delay. With hardware offloading, the port-to-port forwarding and TX packet duplication is offloaded to the PRU_ICSSG cores, so that there is no additional path to travel to the A53 cores to be handled in the Linux kernel. This additionally puts less CPU load on the A53 cores.
You can refer to these resources on more information on running HSR with or without offloading in Linux:
Without HW offload: https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/HSR_PRP_Non_Offload.html
-Daolin