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

[Carl D. Blake]

On Tue, 2007-01-16 at 12:48, Jonathan Larmour wrote:
> Carl D. Blake wrote:
> > I haven't been able to determine why my tcp advertised window keeps
> > decreasing, but I've been investigating why I appear to be receiving
> > corrupted data.  It seems that I'm not actually getting corrupted data. 
> > What's happening is that the lwip device attempts to transmit a packet
> > of data, but it can't allocate a tcp seg.  When that happens it throws
> > away the packet rather than waiting for the number of tcp segs to drop
> > and trying again.  I've just been using the default of 16 for
> > MEMP_NUM_TCP_SEG.  Should I increase this?  It seems odd to me that the
> > system would just throw the packet away.  Is there some way of retrying
> > the packet?
> 
> IMHO the correct solution would be to increase the number of SEGs. If you 
> want to retry the packet, that means putting packets on queues, which means 
> you have to worry about the packets staying there and not being freed back 
> to the system; plus queue management, plus some event mechanism to trigger 
> the retry. This all takes code and RAM resources, and risks causing 
> different resource failures.
> 
> The general philosophy in lwIP is to just drop packets when out of 
> resources. The alternative approach to queue packets would, if extended to 
> cover all situations where that could be argued, lead to large memory 
> footprints.
> 
> Out of interest, I've personally made my number of TCP_SEGs match 
> TCP_SND_QUEUELEN, although that would be overkill for some applications. On 
> a 32-bit architecture, segs are only 20 bytes each.
> 
> Jifl
OK, I've ironed out several problems (most of them mine) and the system
is working much better.  Increasing MEMP_NUM_TCP_SEG to 255 helped with
memory errors (they're gone completely).  I discovered one of my
problems where I was dropping an entire section of my data.  This was
what I thought was data corruption.  I am now able to transmit the data
correctly and consistently.  Now I'm trying to get it to go faster. 
Currently on a 10 Mbps network I'm transferring at 1 Mbps data rate.  I
would like this to approach 5 Mbps at least.  In looking at the tcpdump
I notice that periodically the lwip device is waiting 280 to 450 ms
before transmitting the next section of data.  Normally the delay is
approximately 20 to 40 ms, but every now and then the delay jumps up. 
The tcp window of the receiving end is fairly large (62780).  The data
has all been acked properly (it's not waiting for an ack from the
receiving end).  It just stops for 280 to 450 ms.  I'm examining my code
to see if I can locate a problem there, but I'm wondering if the lwip
tcp stack might contribute to this for some reason.

Thank you so much for your help.  I'm learning quite a bit.