Re: [lwip-users] again: throughput problem

[K.J. Mansley]

On Fri, 2004-03-26 at 12:35, address@hidden wrote:
> /* TCP receive window. */
> #define TCP_WND         32768
>
> /* TCP Maximum segment size. */
> #define TCP_MSS         16384

That's pretty big - much larger than the MTU of the ethernet, so each
TCP segment will get fragmented.  I'd drop this down to <1500 bytes. 

> /* TCP sender buffer space (bytes). */
> #define TCP_SND_BUF     32768 
> 
> 
> Does it make sense to raise the TCP_SND_BUF size again? Is there any
> "optimal" set of settings (rule of thumb?) to reach maximum
> throughput?

There is no magic formula, but your TCP_WND needs to be greater than
(round trip time of network) * (bandwidth you want to achieve) in order
to stream data.  I generally set the snd_buf to be slightly bigger than
the receive window, but they are both pretty large already.  The only
reason you'd need to increase them further is if the above formula isn't
true - i.e. it depends on the round trip time of your network.

> To point 1 (possible mailbox bug in the message api) of my last post:
> This "bug" does no more appear since I have changed the lwip options.
> 
> But sometimes I get the assertion "pbuf_free: p->ref > 0" failed
> (pbuf.c), the same one people had posted before. My function calls to
> lwip are all serialized (one task feeds data into the sockets
> (chargen.c), the TCP/IP-task does the protocol and the timeouts, and
> one task feeds data from the network into lwip, the etharp.c is
> additionally protected by a semaphore), so I think this could be a
> problem of lwip.

Hmm. Not sure then, anyone else got any thoughts on this?  As I can't
reproduce it it'll be pretty hard to track down.

Hope that helps,

Kieran