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

[Kieran Mansley]

On Wed, 2008-10-08 at 16:03 -0400, bill wrote:
> > That truly is weird.  If you can get a packet capture from just before
> > the failure, I'd be happy to take a look.
> 
> I don't know if the text version I sent helped, but I know a lot more now.
> 
> What I see in the packet capture that causes the problem is that the PC
> broadcasts an ARP "who has", 50uS later lwIP sends a response packet to the
> PC. 4uS after that the PC sends 1460 bytes to lwIP, but the sequence number
> is 13140 bytes *ahead* (9 * 1460) of the expect number.  It looks like the
> PC has dropped 9 packets while it was doing its ARP query.  Unless WireShark
> missed these packets (doubtful).
> 
> If I change the PC's ARP table to make the lwIP device static, this problem
> disappears!

It sounds like you've got to the bottom of your problem, but why the ARP
table should need refreshing when packets are being transmitted, and why
the existing entry shouldn't be used while it's waiting to hear the
answer is rather odd.  I wonder if you have two things with the same IP
address on the network, and the PC is getting confused about which MAC
address to use?

> The only thing I see that I don't understand is when lwIP asks for the first
> missed packet, a duplicate request of the same sequence is sent 17uS later.
> I would expect that request to have a more reasonable time before asking for
> the packet again.  Is there a timeout that I can check being set somewhere
> on sending an ack for a missed packet?

You think it should send an ACK faster than 17us?  That's already pretty
quick, particularly if TCP's delayed ACK mechanism is in use.

Kieran