Re: [lwip-users] Duplicated ACK and retransmitted packets - some news

[Lou Cypher]

> I think this setup is fundamentally broken.  You can't do TCP with one
> or even two buffers at the MAC layer and not expect considerable loss.

That sounds fair to me.
Unfortunately ain't so for the FPGA vendor, that provides a MAC peripheral 
having
 "Independent internal 2K byte Tx and Rx dual port
  memory for holding data for one packet"
(from their official documentation)

> TCP's algorithms only really work well when TCP_WND >> TCP_MSS.  A
> sender does not have to provide MSS-sized segments; it could fill the
> window by sending many smaller ones.  You device could receive frames
> from other sources or other connections, and so exhaust your buffers
> just before you get a packet that you really wanted.  All of these mean
> you need many more MAC buffers.

And the best I can have is an
 "Optional dual buffer memories, 4K byte ping-pong,
  for Tx and Rx"
So buffering at most *two* incoming packets.

Have to confess I never made a deep survey on silicon vendors' choices, at MAC
level, in the various devices (i.e. MCUs).
Taking the data sheet of an Ethernet enabled (integral MAC) MCU I see how their
buffering is "smarter", using some buffer descriptors, separating many variable
length packets in a FIFO.
If I return back to the FPGA ip-core, well, no signs of intelligent life, on
that planet (...)

> Sounds OK to me from your description and looking at the capture.
> Packet 30 is lost and lwIP keeps ACKing 29 (i.e. seq 1461) until the PC
> retransmits the data from 30 in packet 35.  lwIP then ACKs all the
> received packets (30/35 + 32) in one go - this is packet 36.

Well, here's how everything goes fine in the end... (beside the needed
retransmission, out of sequence).

I will try fixing the more I can, sadly I can't obtain more MAC buffers
  --Lou looks in his wizard's hat for some blocks of RAM, but it's empty--

Thanks,

~ Lou