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: [email protected] on behalf of TJO Sent: Thu 9/11/2014 4:54 PM To: [email protected] 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 [email protected] 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>>
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
