UDP packet loss

[ismail fatih iltar]

Posted on July 02, 2018 at 13:38

Hi, im using stm32f7+ freertos+lwip (raw api). My system handles web server and udp data communication. My frame length is 572 bytes and my FPS is 40 (22880 bytes/sec) at start. When i increase the package number to 8 times (8*572*40 = 183040 bytes/sec) it drops a lots of udp packages.(Especially dropping starts after 6 times = 6*572*40=137kbits) The weird thing is: if i decrease it to 22880 bytes/sec again it cant returns the normal situation it still drops. I have to reset for normal again. Im not expert lwip so i think there is a problem about buffers. I need an advice.

#ethernet #stm32f7 #lwip #udp #freertos

[AvaTar]

Posted on July 02, 2018 at 14:18

UDP is not a connection-oriented protocol, and does not guarantee delivery.

You need a system that can at least keep up with the frame rate (relevant UDP frames + irrelevant frames).

Change to a Cortex A system.

[ismail fatih iltar]

Posted on July 02, 2018 at 14:37

But someones in market have been made same thing with just Cortex M0. And 137kbits/sec is not big for M7 am i wrong ?

[AvaTar]

Posted on July 02, 2018 at 14:53

But someones in market have been made same thing with just Cortex M0.

Really ?

And 137kbits/sec is not big for M7 am i wrong ?

As a part of your evaluation, you need to examine the gross data rate of the system.

Other application functionality, code inefficiencies and network 'noise' will leave just a fraction available for you.

[ismail fatih iltar]

Posted on July 02, 2018 at 15:19

Sorry not M0 i had to write M3  

>> 

 LPC1766 .

im making controlled tests and i cut out all unneccesary things. Maybe some my udp settings or heap sizes wrongs. But i dont know exactly what i must check. 

[ismail fatih iltar]

Posted on July 03, 2018 at 09:39

To sum up,  a udp pcb or etc. starts to drops packets. and it never comes back to normal condition. Is there any specs that causes this situation ? 

[AvaTar]

Posted on July 03, 2018 at 10:29

Your system - hardware + running firmware - is too slow.

Now it is your task to evaluate if it's caused by inappropriate firmware, or generally inadequate performance of the MCU. But I'm pretty sure it is easy to get the mentioned LPC1766 board into thrashing mode with real-world network traffic.

As said the first time, I would have picked a Cortex A Linux board.

[ismail fatih iltar]

Posted on July 03, 2018 at 16:25

Thank you for your replies AvaTar. But i think cortex m7 mcu that has ethernet with dedicated dma can handle 1.4Mbps udp communication easily. As i say i have a end device for same purpose which is made with cortex M3 and it handles 2.8 Mbps udp comm. and it doesnt drop any package. 

[AvaTar]

Posted on July 04, 2018 at 06:59

Usual networks today have 100MBps or 1GBps, which means about 10 or 100 MByte per second. And the core (your application) must inspect all packages himself. And there are a lot if packages around in a usual office network.

Besides, you need some ressources for the rest of your application. You need to check if this works out - you have the hardware, and know the target environment.

If Cube is the right approach to maximize performance or throughput is another question ...

[ismail fatih iltar]

Posted on July 04, 2018 at 12:53

Thanks again AvaTar for all  your replies and helps. I solved it, the problem is ETH_RXBUFNB at stm32f7xx_hal_config.h. Default value is 4U when i icrease it to 16U the phy to dma communication speed increased. But the CubeMX cant change this value with any graphical tool.I must change it manually for every compile.