Re: Re: Re: Re: [lwip-users] Re: tx badnwidth

[Chen]

The program is supposed to send out data continuously once
the connection is made.

With telnet, Wireshark will not capture these tcp window updating
packets, and the program works as expected.

With a 3rd-party telnet-like program, which I am trying to investigate
more, Wireshark will capture these tcp window updating packets, and the
lwip will stay in the call to
nbytes=lwip_recv(clientfd, buffer,
sizeof(buffer),8),
and won't get out of it until I close the connection, even though the
flag for lwip_recv is NOWAIT.

nbytes=lwip_recv(clientfd, buffer,
sizeof(buffer),8)
is also called in the above telnet case, and it will not block the
process

Thanks


> Date: Thu, 05 Mar 2009 16:08:33
> +0000
> From: Kieran Mansley <address@hidden>
> Subject: Re: Re: Re: [lwip-users] Re: tx badnwidth
> To: Mailing list for lwIP users <address@hidden>
> Message-ID:
> <address@hidden>
> Content-Type: text/plain
>
> On Thu, 2009-03-05 at 10:47 -0500, Chen wrote:
> > Thanks for your suggestion
> > 
> > I increased the TCP_SND_BUF to 32000 and PBUF_POOL_SIZE to 16, and
> the
> > tx and rx ends are fighting now, trying to resolve the tcp
> window
> > update, it seems
> > 
> > please see
> http://www.dataq.com/chen/new.cap
>
> I don't see any fighting there: can you explain what you mean.  It
> looks
> like a packet was lost, lwIP sent duplicate ACKs, the other end
> resent
> it, lwIP acked the retransmitted packet, and they're both now
> waiting
> for the other to send some data.  Which end should have data to send
> at
> this point?  They're both got available window to send if they want
> to. 
>
> > What is the rule of thumb to set up these two parameters? Can
> the
> > first be be larger than 32K?
>
> Yes, I think so.  They're probably restricted in lwIP by the size of
> the
> type used to store them: take a look at the source.  There isn't
> really
> a useful rule of thumb: larger will mean higher throughput until
> something else becomes the bottleneck, then setting them any bigger
> will
> just waste memory.  The best value depends on your system's needs
> to
> trade off performance vs memory, the traffic pattern you expect, the
> way
> the application uses the API.
>
> By setting PBUF_POOL_SIZE to 16, and with each pbuf at 500 bytes 
> (as
> specified in your lwipopts.h) you've got a maximum of 7500 bytes of
> buffering for all the users of pool pbufs.  In reality not every
> pbuf
> will be completely filled, so you'll have a bit less than that
> available.  Therefore setting TCP_SND_BUF to 32000 is probably not
> going
> to make much difference compared to setting it to 7500, as you 
> could
> never put 32000 bytes in the send buffer - there aren't the pbufs
> available to do it.
>
> Kieran