[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Tunning TCP in Lwip

From: Frédéric BERNON
Subject: [lwip-users] Tunning TCP in Lwip
Date: Fri, 3 Nov 2006 15:40:31 +0100

Hi group,

I look for informations about tunning TCP in lwipopts.h. I have to send large 
TCP packets, with minimum delay, so, I try to find in newsletter archives some 
informations. But I don't know exactly which values can impact others ones. Can 
you confirm and/or complete what I found that in archives (I note the archive 
thread where I found the information, if someone what to see more details) :

- TCP_SND_BUF have to be greater than TCP_MSS if TCP_SND_QUEUELEN is defined as 
(2 * TCP_SND_BUF/TCP_MSS). ("TCP_MSS > 1024 No connection" thread)

- "TCP_SND_QUEUELEN... must be less than 256" ("Assertion : "tcp_enqueue: no 
pbufs on queue => both queues empty"" thread)

- TCP_FAST_INTERVAL seems to be a "good" value to reduce to get a minimum 
delay, but increase cycles consume ("TCP performance in receiving" thread and 
"tcp_tmr - TCP_TMR_INTERVAL" thread)

- TCP_WND have to be big enough to avoid to reduce exchanges when this "window" 
is full ("TCP performance in receiving" thread)

- in tcp.c, tcp_recved, reduce TCP_WND/2 can improve perf, in  line "else if 
(pcb->flags & TF_ACK_DELAY && pcb->rcv_wnd >= TCP_WND/2) {" ("TCP performance 
in receiving" thread)

- prioritize the API_MSG_RECV... if your mailbox interface supports this ("TCP 
performance in receiving" thread)

- MSS: 1460, TCP_WND: 24000, TCP_SND_BUF: 16*MSS, TCP_SND_QUEUELEN: 16, this 
settings have increase perf form 9 to 12.9Mbps on a uCOS device ("About the 
throughput of LWIP" thread)

- PBUF_POOL_BUFSIZE set to 2048 increase perf but consume more RAM ("About the 
throughput of LWIP" thread)

- TCP_WND have to be at least a couple of segments ("lwip connect to normal 
socket applicationveryvery slowly" thread)

- TCP_NODELAY disable the Nagle algorithm but not in raw layer. A quick change 
in do_write() can also imcrease perf. ("Sending too slow" thread)

- Sending two small packets (730 bytes if MSS is 1460) can give better perf 
than 1, because ACK is forced to be send by peer. ("Long(er) delay to PC ACK 
when serving images" thread)
Do you see more "rules" to respect ? (I hope I don't have write silly things)

Thank you for your help...

Frédéric BERNON 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]