Re: [lwip-users] TCP speed drops to a crawl.

[Michael Williamson]

Hi,

It appears that altering the MEM_SIZE (not TCP_SEND_SIZE) has a linear 
impact on when this issue occurs.  When it's set to 1600, we drop out at 
3100 packets, when it's set to 512000 we drop out at ~100000 packets.  
With TCP_NODELAY set, I would expect that the rate of transmission not 
be tied one-to-one with the client ack rate, no?  That's the behaviour 
when things slow down.

A couple of other test observations:

When large messages are used (i.e., messages that require breaking into 
multiple packets, say 10Kbytes), this problem does not present itself.  
Seems to be related to smaller packet sizes.

If you disconnect and then reconnect the client, the rates go back up 
and then drop again.  It's very reproducable.

I'm beginning to wonder if there is a problem cleaning up buffers tied 
to large groups of ack'd packets?  Is there a limit to the queue size of 
unacknowledged buffers that could be getting overrun?

Thanks again,

-Mike

Adrian Godwin wrote:

> Michael Williamson wrote:
>
> > Hi,
> >
> >   I am fairly new to lwip.  We are using lwip 1.1.0 with a port to 
> > TI's Code Composer BIOS for a 6711 processor.  The stack seems to be 
> > working, but we are seeing a strange behaviour with a simple TCP 
> > packet throughput test that smells like a configuration problem.  We 
> > are using the BSD sockets.c style API and have code that looks 
> > something like that below.
> > If we set TCP_NODELAY, we get about 3100 packets very quickly (about 
> > 1000 per second) then the rate drops substantially and it looks like 
> > (using ethereal) the lwip stack is waiting for an ack sequence from 
> > the client before sending any new messages.  Our client (telnet on a 
> > PC running Windows 2000) is ack'ing packets on a 200 ms latency, so 
> > we are seeing packet messages at about a 5 Hz rate instead of the 
> > 1000 Hz rate we were expecting.  No packets are dropped or timed out 
> > in the transaction sequence, just stopping until an ack is received.
> >
> > We're wondering if there is something like a water mark or some other 
> > configuration in the lwipopts.h that might present such a 
> > behaviour.   I've included our settings after the pseudo code below.
> >
> > Any insight would be greatly appreciated.
>
>
> I found a PC client acking slowly because the TCP window wasn't
> filled : it was expecting further frames because they were
> invited, but lwip didn't send them.
>
> The amount of data lwip is prepared to push into the window is
> conditioned in the BSD sockets API primarily with logic
> related to TCP_SND_BUF. The PC is inclined to offer quite a
> large window (64k).
>
> -adrian
>
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users

michael.williamson.vcf
Description: Vcard