lwip-users
[Top][All Lists]
Advanced

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

RE: [lwip-users] Significant overhead periodically during TCP receive tr


From: Kieran Mansley
Subject: RE: [lwip-users] Significant overhead periodically during TCP receive transfers
Date: Wed, 08 Oct 2008 08:43:07 +0100

On Tue, 2008-10-07 at 13:24 -0400, bill wrote:
> > Kieran Mansley wrote:
> > >> Thank you for any feedback on this.
> > >>
> > >
> > > I don't know of any timers that have that periodicity in lwIP.
> > None.
> > > It might
> > > be useful to get a packet capture from just before the poor performance
> > > that we could look at in ethereal - that might give a clue about why the
> > > performance is poor.
> > >
> > The first thing I would do is to check whether this is a real delay in
> > your device or a simple TCP retransmission delay (i.e. the first
> > response has a bad checksum or something like that and the PC has to
> > wait for the device to retransmit).
> > I strongly suspect the latter.
> 
> Thanks to both of you.  I wanted to add to lwIP_stats when retransmissions
> occur so I know if something was missed or there are errors.  I had trouble
> finding where all of the error recovery retransmissions occur.
> 
> Is putting debug traces in tcp_rexmit_rto sufficient to catch when they
> occur?

No, that will only get retransmissions after a timeout, not the fast
retransmissions after duplicate ACKs.  You also need to trace tcp_rexmit
()

> One point is truly interesting.  I can send 10MB/S (1MB every 100mS) for
> ~9.5 minutes, or sit for 9 minutes while sending the 836 byte "I'm here"
> packet once per second and then start the 1MB/100mS transfers and at ~9:30
> it fails.  There have been a few times that I've seen a program crash or
> memory corruption but most often the drop in bandwidth is what starts things
> off, and it is repeatable (from 9:25 to 9:40).  The time seems to start then
> the connection is made.  It doesn't matter how long the firmware is running
> before the connection takes place.  The connection can be terminated from
> the PC and reconnected and it still times out at 9:30 or so from the first
> connection.  It makes it seem like an uninitialized variable in the
> connection management.

That truly is weird.  If you can get a packet capture from just before
the failure, I'd be happy to take a look.

Thanks

Kieran







reply via email to

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