End-to-End latence testing

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

End-to-End latence testing

776 Views
mingzheliu
Contributor I

Hi,

I am using RT1064 to test the end-to-end latency of Ethernet. The SDK version is 2.7. There are 20 nodes in the network, and all nodes are synchronized in time. Each node sends multicast data in a periodic time, records the node sending time before sending, and records the node receiving time after receiving interruption. We found that the end-to-end delay is at least 5ms, which feels a little too much.

But the strange thing is that as the number of network nodes decreases, the end-to-end delay increases. If there are only two nodes, the end-to-end delay will increase to more than 100ms. We suspect that the interruption delay is too long to cause this phenomenon. But I don't know why the network delay varies with the number of nodes.

Is it possible that the receiving interrupt occurs because the received frame reaches a certain number or time? But we did not set interrupt coalescence.

 

thank you

0 Kudos
5 Replies

739 Views
mingzheliu
Contributor I

Hi,

Thank you for your reply.

The SDK version we are using is 2.7.0, and the AN12149 patch is applied. FreeRTOS is used, no Lwip.

Before sending data, we record the time when the data was sent. When receiving data, we measured the time to receive the data in the interrupt handling function. The measured end-to-end delay has a minimum of 5ms, and the measured value will increase as the number of network nodes decreases. There is no problem with time synchronization, and the hardware time stamp is also correct. We think that the delay in interrupt processing is a bit large, but we don't know what the problem is.

We see that ENET supports the function of interrupt aggregation, but it is disabled.

0 Kudos

760 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi mingzheliu,

   You mentioned Each node sends multicast data in a periodic time, then you test the end to end latence.

   Do you try to configure the loopback mode, what about this mode latence time?

  When you test the multicst data in a periodic time, what the periodic time you are using?

 

Wish it helps you!

If you still have questions about it, please kindly let me know!

Best Regards,

Kerry

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

-----------------------------------------------------------------------------

0 Kudos

756 Views
mingzheliu
Contributor I

I did not configure the lookback mode. I did not use TCP/IP, but sent Ethernet frames directly. The sending cycle is 50ms and each node sends a frame every cycle.

0 Kudos

750 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi mingzheliu,

  Which detail SDK code you are using now? Just let me know how to reproduce your issues with the SDK code.

 

Wish it helps you!

If you still have questions about it, please kindly let me know!

Best Regards,

Kerry

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

-----------------------------------------------------------------------------

   

0 Kudos

718 Views
mingzheliu
Contributor I

Hi,

Thank you for your reply.

The SDK version we are using is 2.7.0, and the AN12149 patch is applied. FreeRTOS is used, no Lwip.

Before sending data, we record the time when the data was sent. When receiving data, we measured the time to receive the data in the interrupt handling function. The measured end-to-end delay has a minimum of 5ms, and the measured value will increase as the number of network nodes decreases. There is no problem with time synchronization, and the hardware time stamp is also correct. We think that the delay in interrupt processing is a bit large, but we don't know what the problem is.

We see that ENET supports the function of interrupt aggregation, but it is disabled.

0 Kudos