Re: [lwip-users] TCP performance in receiving

[Sigurd Vindenes]

Hi,

some coleagues and I just had our own round on this before spotting this
discussion. Just wanted to mention our  conclutions and solution since they
seem to be slightly different from yours:

Parameters:
TCP_WND=5840
TCP_MSS=1460

When receiving from a fast source (a PC), the PC will quickly send the
5840/1460=4 frames that fit into the window.

Those frames will be queued up to the TCP task through the tcp_input()
function. We're using a queue length of 5 here.

Meanwhile our receiving task wakes up and does an lwip_recv() that
eventually causes an API_MSG_RECV message to be queued up to the TCP task
( api_msg_post() in netconn_recv() ). This is the message that makes the TCP
task do the do_recv() -> tcp_recved() calls that  causes a window-opening
ack to be sent.

The problem is that all the messages to the TCP task are processed in
sequence, so the fast sender will always manage to squize in
TCPIP_MSG_INPUT messages before our server task sends the API_MSG_RECV
message. This stalls the sender while we are processing the data.

Our solution was to prioritize the API_MSG_RECV messages above all other
messages to the TCP thread. This can be accomplished by a send to front of
queue call if your mailbox interface supports this, or, as in our case by
implementing a priority queue based on a standard queue interface.

The solution might seem complex, but the result was a whopping speed
increase from 30 Kbyte/s to 720 Kbytes/s on our platform! Thats 24 times :-)

Don't know if we're using the stack the same way you are though, but if this
makes sense to anyone they may give it a try :-)

Best regards,
Sigurd Vindenes.



----- Original Message ----- 
From: "K.J. Mansley" <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Saturday, October 16, 2004 3:10 PM
Subject: Re: [lwip-users] TCP performance in receiving


> On Tue, 2004-10-12 at 12:31, Craig Graham wrote:
>
>
> > tcp_recved() mod (Atte, threshold==TCP_WND/2) 31s        238%
>
> Thanks for taking the time to test and profile all these!
>
> I've committed a fix, and opted for the middle of the range (in terms of
> agressiveness) TCP_WND/2 as the threshold.  This can be tuned to
> whatever you want if you need the extra few %.
>
> Was a bug report filed on savannah for this problem?  I couldn't see
> anything to close when I checked in the fix just now.
>
> Thanks
>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users