-
|
I am evaluating Zephyr for one of the upcoming product development and found that the real time performance is greatly affected when there is traffic in the network interface. The way I do my test is as follows.
I see that when no network traffic the results are ok. But when there is network traffic, the values even shift more than 500μs on an STM32 board. On an NXP board it is even worse like 3+ ms jitter.
I tried to search for configuring the network priority, but I could not find any useful information. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 5 replies
-
|
If co-operative threads are enabled, then by default network threads are run in co-operative mode. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @jukkar thanks for the response. In our application, if the jitter of the real time task is above 100μs, it is not acceptable. Why ethernet is causing a lot of jitter in the realtime task? is it because of the Ethernet generating a lot of interrupts? |
Beta Was this translation helpful? Give feedback.
-
|
Difficult to say, I am not very familiar with what the vendor Ethernet driver is actually doing. You can also experiment with the TX/RX thread priority by setting |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure this is the one but eth_stm32_hal.c has the following block in while ((pkt = eth_rx(dev)) != NULL) {
iface = net_pkt_iface(pkt);
#if defined(CONFIG_NET_DSA)
iface = dsa_net_recv(iface, &pkt);
#endif
res = net_recv_data(iface, pkt);
if (res < 0) {
eth_stats_update_errors_rx(
net_pkt_iface(pkt));
LOG_ERR("Failed to enqueue frame "
"into RX queue: %d", res);
net_pkt_unref(pkt);
}
}This means that when the device is kept receiving packetes, it won't leave the function. The thread which calls this function is created as: /* Start interruption-poll thread */
k_thread_create(&dev_data->rx_thread, dev_data->rx_thread_stack,
K_KERNEL_STACK_SIZEOF(dev_data->rx_thread_stack),
rx_thread, (void *) dev, NULL, NULL,
K_PRIO_COOP(CONFIG_ETH_STM32_HAL_RX_THREAD_PRIO),
0, K_NO_WAIT);
|
Beta Was this translation helpful? Give feedback.
-
|
@yashi thanks for the answer. Now I need to find whats wrong with nxp driver. |
Beta Was this translation helpful? Give feedback.
-
|
NXP has fixed the issue with the pull request The issue in STM32 HAL also should be raised as a bug? i think it is not the right way to create a cooperative thread directly from HAL like that. At least it should be configurable by the user. |
Beta Was this translation helpful? Give feedback.
-
Sure, please create an issue for that. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, @aneejosep Changing thread priorities can help. These changes set the networking and system work queue threads to be preemptive, and allow an application thread to preempt them. Executing from internal ITCM SRAM also provides a major performance boost over external QSPI flash. The entire application can be moved to ITCM in devicetree by setting the chosen node |
Beta Was this translation helpful? Give feedback.
-
|
The issue in STM32 HAL is fixed with this pull request |
Beta Was this translation helpful? Give feedback.
I'm not sure this is the one but eth_stm32_hal.c has the following block in
rx_thread()This means that when the device is kept receiving packetes, it won't leave the function. The thread which calls this function is created as: