Re: [lwip-users] Handling of many small packages?

[Noam weissman]

Hi,

You may need to change lwipopts.h file.

Create more PBUF, more PCB's reduce the MSS size etc...

This way it will be more optimized for smaller chunks of data.

Also you may check the TCP window and buffer size before trying to send 
some data out. You need a way to control how you use the stack in order 
not to get low on memory.

BR,
Noam.


-----Original Message-----
From: address@hidden on behalf of TJO
Sent: Thu 9/11/2014 4:54 PM
To: address@hidden
Subject: [lwip-users] Handling of many small packages?
 
Hi

I use the tcpecho sample with FreeRTOS for EA dev kit.
I have re-written it so it makes connection to server, instead of listen.

>From the server i send 14 bytes in a packet
Then it sends 512 bytes in a packet.

Every time the tcpecho sample receives a message it returns 14 bytes



But if I send the 512 bytes in 128 bytes chunks (4x stream.Write(byEthRaw,
0, 128) ) from the server, it is just matter of time before it begins
generate a lot of retrans on my network and ultimate stop working.
According to the debugger the application still runs, but can't ping the
lwip and no data is send on the network. The debug output from lwip also
stops!

It seems it runs out for allocation space for pbufs.
The demo runs in internal PIRAM, so not a lot of space here. But I do not
generate that much traffic either.

If I don't send data back from the demo app it runs for ever!

I also have enabled filtering en the EMAC, so I don't get all the brodcasts
on the network.

Any suggestions what may be wrong? or where to adjust?

Code where i receive and send:

while ((err = netconn_recv(conn, &buf)) == ERR_OK) 
{
        do {
             netbuf_data(buf, &data, &len);
        } while (netbuf_next(buf) >= 0);
        netbuf_delete(buf);
        netconn_write(conn, dummy, 14, NETCONN_COPY);
}

The last debug info from lwip: (I use the serial debug viewer and it cant
handle that much data, so sometimes the debug text get partially overwritten
by a new line)

pbuf_alloc(length=20) == 20001898
pbuf_header: old 200018cc new 200018b8 (20)
pbuf_header: old 200018b8 new 200018aa (14)
lpc_low_level_output: pbuf packet(200018aa) sent, chain#=0, size = 54
(index=1)
plbufpc_tx_recpbuf_alloc(l_free(200018laim_st: Freength=1536)98)
pbuf_freeing packet 
lpc_rx_queue: 2000189820001898 (ine: could not has ref 1, dex 1)
pbuf allocate RXending here._free(20001 pbuf (free 
898)
pbuf_desc=1)
lpc_free: deallrxqueue_pbufocating 2000: pbuf pack1898
et queued: 20004748 (free desc=0)
lpc_low_level_input: Packet dropped since it could not allocate Rx Buffer
pbuf_alloc(length=1536)
lpc_rx_queue: could not allocate RX pbuf (free desc=1)
lpc_rxqueue_pbuf: pbuf packet queued: 20005f90 (free desc=0)
lpc_low_level_input: Packet dropped since it could not 
lpc_rxqueue_pbuf: pbuf packet queued: 20006bc0 (free desc=0)
lpc_low_level_input: Packet dropped since it could not allocate Rx Buffer
pbuf_alloc(length=1536)
l



--
View this message in context: 
http://lwip.100.n7.nabble.com/Handling-of-many-small-packages-tp23251.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.
************************************************************************************







************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.
************************************************************************************

<<winmail.dat>>