This is the mail archive of the
ecos-discuss@sourceware.org
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
> consistent...
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.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss