Re: [lwip-users] Re: Desired - reference netconn_write() to external memory

[Tom Hennen]

You may not have enough memory for the receive window you've specified.

 

TCP_WND doesn't actually allocate any memory by itself, you'll need to make sure you have enough memory in the pbuf pool or on the heap (if you can allocate incoming packets from the heap) to accommodate the promise made by TCP_WND.

 

Also remember TCP_WND refers to the TCP payload, you'll need to have space for the headers and other structures as well.

 

Tom
 

On 10/11/06, Çağlar AKYÜZ <address@hidden> wrote:

Kieran Mansley yazmış:
> On Wed, 2006-10-11 at 16:25 +0300, Çağlar AKYÜZ wrote:
>
>
>> Actually I think this will not improve the performance of MAC. Because
>> ACK'ing of TCP frames is one of the major drawbacks which degrades
>> performance ( thanks to Delayed ACK algorithm!).
>>
>
> Only in a very limited set of circumstances will the delayed ACK
> algorithm result in poorer performance.  Namely, when the TCP window has
> been set to a very small value.  Changing this configuration option will
> remove any bottleneck that the delayed ACK algorithm is imposing.
I tried to increase recieve window but it always resulted in a poorer
performance with my SAM7X. ( Maybe I'm too low in memory?) . is TCP
window size related to somewhat pbufs? I don't know if I have to
increase number of buffers as well.
> There
> are TCP extensions such as the "quickack" mode in linux's TCP stack that
> stop the use of delayed ACK during the slow start phase of TCP
> connections, but the performance difference that this is likely to lead
> to in lwIP is minimal.
>
Actually I didn't mean to say that problem is related to LWiP. I wanted
to say that delayed ACK algorithm is slowing TCP connections in our case
and my Windows machine do not provide me any way to change this setting.
( Thanks to Linux as you noted. )
> ACKing of packets can be arguably said in fact to increase performance,
> as without it the sender couldn't discover the maximum rate it could
> send without packet loss, and so if it didn't wish to lose data would
> have to be more conservative with how fast it sent packets.
>
Thanks for this quote. I'll remember this.

Çağlar


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