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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
