UDP packet loss on the gigabit full duplex ethernet network

My problem if I send a large UDP data (about 70kB) to the Apalis module, it is often lost, but only if 1Gbps full duplex mode is set on the sender side. Everything else works fine in other case (gigabit half duplex, fast half and full duplex). I tried to change the duplex mode in the registry, but it had no effect and my router always detect 1Gbps full duplex mode. I tried with direct connection to the PC without router, the result was the same.

Dear @vighbalazs,

Thank you for contacting the Toradex community!

May I request to test the same case with Linux operating system? Quickly I searched in our database, I didn’t find any such issue.

Program Linux image using Toradex easy installer. It is nicely documented here: Toradex Easy Installer

After that to test the Ethernet follow this documentation: Ethernet/Network (Linux) and https://www.toradex.com/community/questions/19723/apalis-imx6d-problem-with-transferring-huge-files.html

If you feel, it is not easy to test on Linux then Could you write detailed step by steps instructions with tools to reproduce the issue on our side. It will save us time to reproduce and write a test tool to verify the issue.

Thank you for your understanding.

I don’t know linux, so I tried to reproduce the problem with a simple program. The test program is a simple echo program, send back the received data. I found when the PC send data in a small packets in a burst (40 * 1500kB), a few packet lost (apalis module not received) at gigabit/s speed, but at 100Mbit/s was good. I checked the communication by the wireshark software, and it said the time between the sended packet is about 0.00001-0.00006 second in both cases. So maybe there is an overflow or congestion somewhere at gigabit speed? I tried to set the input buffer size large (200000kB) with the
setsockopt(, SOL_SOCKET, SO_RCVBUF, , ) function, but it had no effect.

UDP is not guarantee a delivery so if percentage of loss packet is small it’s should be considered normal . Did you try to connect any other SBC with 1GB Ethernet running same test program and check a loss rate?

Thank you for your answer. I tested on linux and i got the same result. The packet loss rate was between 7-15% (also on Windows). We don’t have other SBC, but we checked the loss rate with a laptop, and we got 0% lost packet from 10000 packet. So can be it a hardware limitation? If you have no other idea, the solution will be to use on 100Mb/s speed.

Thank you for the information.
I attach the photo of the module.
[upload|3tl0Ckq3r3D4BSd6HSI28pkdt/A=][upload|zW9BjEj4Gkp6DcBZVS0aLXJGN38=]

Dear @vighbalazs,

Thank you for your reply.

At the moment, this would be a hardware limitation because of Jumbo frames limitation. If you are expecting a very quick fix, we would like to suggest to use 100Mbit speed, there is a registry for that.

Theoretically, You need to play around below options for the problem if there is no hardware limitation

  • Socket buffer
  • Ethernet large packet
  • Increase ethernet queue

We found this documentation : https://www.researchgate.net/publication/317300297_Achieveing_reliable_UDP_transmission_at_10_Gbs_using_BSD_socket_for_data_acquisition_systems, this would be quite useful for you.

Please refer this thread for Ethernet jumbo frame limitation : https://www.toradex.com/community/questions/32274/enable-jumbo-frames-for-ethernet.html

Could you share module serial number with version information, clear top view photo would be very helpful. I will try to verify from the production log messages, Is there any such hardware problem?

Hence, we would like to suggest to use Linux and play around with 3 options to find the optimum settings to suppress the packet loss error on UDP with 1GB speed. Also, please share it with us. We will try to set similar settings in WinCE. As you know, at the moment this would be a time-consuming task for us.

Thank you for your understanding.

Dear @vighbalazs,

We don’t find any fault in our production logs on this module. Still, if you see packet miss with Gigabit UDP protocol then it must be the nature of the i.MX6 performance with UDP.