[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Williamson
Subject: Re: [lwip-users] TCP speed drops to a crawl.
Date: Thu, 11 Aug 2005 09:30:24 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)


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,


Adrian Godwin wrote:

Michael Williamson wrote:


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).


lwip-users mailing list

Attachment: michael.williamson.vcf
Description: Vcard

reply via email to

[Prev in Thread] Current Thread [Next in Thread]