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

[bill]

> 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?

This is documented behavior in Windows and the time it polls varies between
2000, 2000 Server, XP and Vista.  Checking every 10 minutes is documented
for XP and there are other references on the Internet for this behavior
causing problems for people.

> 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.

No, no, sorry, the duplicate ACK is 17uS after than the first duplicate ACK
- I would have expected a longer timeout before it sends the duplicate
again.

This is clearly a Windows problem in that it drops outgoing packeting while
it's sending the ARP request and getting the response.

For lwIP, I don't think the burst of duplicate ACKs (i.e. identical packets)
in a very short period look correct.  Often lwIP can recover from these
dropped packets, but we have seen it crash a number of times trying to
recover (memory overwrites in our program).

Bill