Re: [lwip-users] losing input packets and repeated acks

[Carl D. Blake]

Things are improving, just not perfect yet.  I rewrote the low level
ethernet driver to use pbufs directly.  Doing that seems to have stopped
the pbuf allocation errors.  The maximum used pbufs according to stats
is now 40.  It never uses all of the pbufs anymore.  My huge delay
appears to be gone.

The behavior of the system is now that the first couple times I transmit
1 Mbyte it goes very quickly.  After that the time it takes to transmit
1 Mbyte begins to increase steadily.  Examining the tcpdump shows that
my lwip device that is receiving the data begins to advertise a smaller
and smaller window.  The window never goes back up to 16Kbytes.  I'll
wait a few minutes before starting another transfer and the lwip
device's advertised window starts at the smaller size.  Any ideas?

On Mon, 2007-01-15 at 11:18, Carl D. Blake wrote:
> On Mon, 2007-01-15 at 10:48, Jonathan Larmour wrote:
> > > I made the changes you suggested and things are a little better.  I'm
> > > still getting the huge delay periodically, but the multiple acks of the
> > > same packet and the same window size are gone.  I still get multiple
> > > acks of the same packet, but the system seems to be advertising a larger
> > > window size for each ack.  I seem to be getting some corrupt data, but
> > > it's not nearly as bad as it was before.
> > 
> > Missing data is one thing, but corrupt data implies to me that there is 
> > something more problematic going on at a lower level, possibly hardware, 
> > more likely your software ethernet device driver.
> > 
> Hmmm.  I'll look at this possibility more closely.
> 
> > > I enabled LWIP_STATS and printed out the stats before and after the
> > > transfer.  TCP stats is reporting several checksum errors.  PBUF stats
> > > is reporting several errors.  I enabled debug messages for pbufs and I'm
> > > getting the message "pbuf_alloc: Out of pbufs in pool."  This happens
> > > quite a bit during the transfer of 1 Mbyte.  I hadn't expected this to
> > > be a problem since my pbuf memory is 45Kbytes and my TCP window is
> > > 16Kbytes.  Any other suggestions?
> > 
> > Indeed the remote side should not send more data than the receive window, 
> > although it may use up a few more pbufs with things like acks. I guess you 
> > could try and find out where the pbufs are going - it's possible your 
> > driver might be leaking pbufs. When the stack goes back to quiescent, do 
> > the stats return to the starting state? i.e. record stats, exchange lots of 
> > data for a bit, stop exchanging data, record stats again.
> > 
> When the stack is quiescent the stats return to the starting state.  The
> PBUF stats show 90 available and 0 used.  I don't think I'm leaking
> pbufs.
> 
> > Jifl
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>