This is the mail archive of the
mailing list for the eCos project.
Re: A&M Rattler and TCP performance
- From: Andrew Lunn <andrew at lunn dot ch>
- To: John Doe <johndoe935 at hotmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Thu, 15 Dec 2005 17:24:33 +0100
- Subject: Re: [ECOS] A&M Rattler and TCP performance
- References: <BAY112-F6E55EA9AFE1DBE358699A9D3B0@phx.gbl>
On Thu, Dec 15, 2005 at 01:21:26PM +0000, John Doe wrote:
> Hi, all.
> I'm developing an embedded application using eCos on a PowerPC target, and
> I'm experiencing very poor ethernet (TCP) performance with my target,
> wondering if it is an eCos/HAL bug, poor configuration (user error, user
> being me...), or a hardware problem.
> The problem is only for TCP reads (host->target), giving typically
> 100-200kBytes/sec. TCP writes are fine, with 6-8MBytes/sec. UDP read/write
> also seems OK, giving around 1-2MBytes/sec depending on the application
> used for testing.
> Using tcpdump and ethereal on a minimal test application sending data from
> the host to the eCos target, I can see several odd things :
> 1) The preformance is very good in short bursts, typically for a few
> milleseconds, before it stalls. The host stops sending data. The target
> seems to have ACKed perfectly OK, indicating a TCP window with plenty of
> space left. Then there is a delay, before the target probaly times out and
> resends an ACK, and the host continues transferring. The target time-out
> occurs exactly every 100ms.
> - It seems the host is causing the problem here, since it stops sending for
> no apparent reason
> - this only happens when the target is eCos.
Please could you post a trace from tcpdump.
It is unlikely to be a host problem. It is more likely the host is
simply responding to what the target has told it to do.
> 2) there are quite a few (~10%) retransmits, but the host detects these,
> and does fast retransmits, giving no stalls in the data transfers.
> - Should I worry about these? I guess it should never happen.
This is not good. 10% packet getting loss it way too high. You should
investigate this. You might want to see if you are running out of mbuf
or clusters. This would cause a discard and so a retry.
> 3) Before every stall, ethereal labels the last ACK from the target as a
> "TCP window update". I have no clue what to make of this, but it seems very
Is it trying to make the window smaller? My guess is it is. Making the
window smaller could indiate it is running out of buffers.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss