RAM usage of FreeRTOS+TCP

system · May 27, 2019, 7:04am

edeviser wrote on Monday, May 27, 2019:

First of all I would like to say that I am so thankfull to the +TCP extension to FreeRTOS. It has powered up my projects an runns very CPU performant on my STM32.

Well, due to some low RAM problems I diskussed two posibilities to reduce RAM usage by +TCP:

Limit the count of connections to 1 by using the reuse socke option: LINK
Reduce the MTU size: LINK

Nevertheless I went on inspecting the behavior of +TCP and its inpact to the heap utilisation by printing the xTCPPacket.xEthernetHeader.usFrameType inside the EMAC task in NetworkInterface.c:674. To my suprise I saw, that sometimes there are more than 30 ARP frames per second. For every ARP Frame the EMAC Task allocates some ram sends this frame to the higher level IP-Task which then evaluates the ARP frame and frees the memory.

Looking at these large amaout of traffic which is caused only by the adress resolution protocol (ARP) I wonder what is it worth of dealing with my approach number one of limiting the count of connection. My project is running inside a large network with man network peers. Having a closer look to the ARP frames showed that sometimes up to eight ARP-Connection driven by other network peers are done at the same time!

So I would like to ask:

Is it normal that processing for +TCP to process that much ARP packages?
Is it normal that ARP-connections are processed in parallel?
Is there any other option of optimizing the RAM usage caused by the adress resolution protocol (ARP) ?

Appendix: Log of the Frametypes:

xTaskGetTickCount: usFrameType:
Time:      49000   FrameType:1544
Time:      49000   FrameType:1544
Time:      49000   FrameType:1544
Time:      49001   FrameType:1544
Time:      49001   FrameType:1544
Time:      49001   FrameType:1544
Time:      49001   FrameType:1544
Time:      49002   FrameType:1544
Time:      49002   FrameType:1544
Time:      49103   FrameType:1544
Time:      49104   FrameType:1544
Time:      49211   FrameType:1544
Time:      49289   FrameType:1544
Time:      49394   FrameType:1544
Time:      49422   FrameType: 8
Time:      49423   FrameType: 8
Time:      49488   FrameType:1544
Time:      49566   FrameType:1544
Time:      49613   FrameType:1544
Time:      49634   FrameType:1544
Time:      49634   FrameType:1544
Time:      49660   FrameType:1544
Time:      49971   FrameType:1544
Time:      49972   FrameType:1544
Time:      49972   FrameType:1544
Time:      49972   FrameType:1544
Time:      49972   FrameType:1544
Time:      49973   FrameType:1544
Time:      49973   FrameType:1544
Time:      49974   FrameType:1544
Time:      49974   FrameType:1544
Time:      49974   FrameType:1544
Time:      49974   FrameType:1544
Time:      49988   FrameType:1544
Time:      49988   FrameType:1544

htibosch · May 27, 2019, 7:42am

heinbali01 wrote on Monday, May 27, 2019:

Limit the count of connections to 1 by using the reuse socke option: LINK

Reuse socket ( FREERTOS_SO_REUSE_LISTEN_SOCKET ): A TCP server socket can turn itself into a connected socket. That option is only applicable to TCP, not to ARP or UDP.

Is it normal that processing for +TCP to process that much ARP packages?

It might happen on a large network. I’m surprised that you don’t also see lots of UDP broadcasting.

Did you find out who is sending all those ARP packages? What kind of ARP packages are they?

Is it normal that ARP-connections are processed in parallel?

ARP is connectionless. In most cases, you will see:

Q: Who has IP-address 192.168.x.x ?
A: I am 192.168.x.x ? with MAC address y-y-y-y-y-y

Beside that, there is the gratuitous ( unsolicited ) ARP message: it only expects an answer from a peer who happens to have the same IP-address.

I attach a short PCAP showing the 3 ARP packets: ~arp_requests.pcapng"

Is there any other option of optimizing the RAM usage caused
by the address resolution protocol (ARP) ?

It is a nasty problem. It may force the Network Interface to drop important TCP/UDP packets because all buffers are occupied with ARP packets.
It might be useful to do some quick pre-filtering here.

Receiving lot of ARP packets may also spoil your ARP table. Suppose you look-up a peer, then after a few seconds, the ARP entry will be re-written by another unsolicited ARP reply.

I once had an embedded device in a large LAN. It could hardly function normally because of the frequent UDP broadcasting. We solved it by early filtering. The earlier the better.

On remark about TCP and buffer space: have a look at the socket option FREERTOS_SO_WIN_PROPERTIES. It lets you determine the TCP window size and the buffer sizes in both directions.
Apply the socket options to the (listening) parent socket: it will be inherited by the connected (child-) socket.

If TCP speed is not important, you may consider to define:

#define ipconfigUSE_TCP_WIN		0

The length of the TCP window will be equal to MSS. This saves a lot of RAM and code.