search

CNES / opensand

28 stars 6 forks source link

GSE / UdpChannel errors + Strange RAM behaviour #8

Open diegotuzi opened 9 months ago

diegotuzi commented 9 months ago

Dear Opensand developers,

I'm using OpenSand in a simple configuration: one ST, one GW and one SAT. On the LAN GW there is another VM with an Iperf server, and on the other side there is a VM with an Iperf client. Ideal conditions: high SNR, no attenuation, fixed delay.

The setup works for a while without any problems, but after a while (depending on the baud rate) the throughput decreases/oscillates and eventually goes to zero and one of the opensand VMs crashes.

Testing the return link, these are the errors: [2024-01-31 16:09:55.071][ERROR][st1][encap.gse][Gse.cpp:deencapPacket():852] GSE deencapsulation failed (Packet is too long for the deencapsulation buffer: PDU dropped), drop packet [2024-01-31 16:09:52.903][ERROR][st1][sat_carrier.channel][UdpChannel.cpp:receive():449] we may have lost UDP packets, check and adjust UDP buffers

I varied the packet size in Iperf3, but the results is still the same.

I also noticed a strange behaviour in the RAM of the terminal VM. RAM keeps increasing during the Iperf3 test and does not go down.

This is monitoring of the RAM of the terminal VM. image

Testing the forward link, there are similar errors in the gateway and the same strange RAM behaviour in the gateway VM.

It seems that the traffic is allocated inside the ram and never freed.

Quick update 02/02/24: the problem is present only when using SCPC.

Thank you in advance for your help.

Best regards, Diego Tuzi

Kniyl commented 6 months ago

Hi,

Sorry for the late reply.

We fixed a few memory leaks a couple month back in the dev branch and are in the process of updating the gse plugin to allow the use of a more modern and standard-friendly library instead of the current one. I hope this will help solve your issues.