This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A&M Rattler and TCP performance

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.


Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]