Re: [lwip-users] TCP bandwidth limited by rate of ACKs

[Mason]

Bill Auerbach wrote:

> Mason wrote:
>
>> I was expecting to reach 80+ Mbit/s, so I captured the conversation
>> with Wireshark, and I noticed that the sender is being throttled
>> because the receiver (the STB running lwip) is not sending ACKs
>> fast enough.
>>
>> cf. STB_TCP_RX_2.pcap (6 MB -- I truncated payloads to 100 bytes)
>> http://dl.free.fr/tKDBuYTrc
>>
>> Can someone nudge me in the right direction to optimize my
>> build of lwip?
> 
> Some things are to optimize are the internet checksum,

As a first-order approximation, I simply disabled CHECKSUM_CHECK_TCP.
I don't think the IPv4 checksum check (20 bytes) has much of an impact
on performance, do you?

> use zero-copy receive and transmit,

I wish I could, but I've no idea how to accomplish that.
cf. my previous thread "Custom memory management"
http://lists.gnu.org/archive/html/lwip-users/2011-10/msg00008.html

> do SMEMCPY more efficiently,

I'm not sure I can do it better than my platform's memcpy.

> review/optimize memcpy,

I will try profiling to see if we're indeed spending most of
the time copying data.

> and use RAW API.

I can't. I need to implement the BSD sockets API.

> Use LWIP_CHKSUM_ALGORITHM = 3 as it looks like it might be the best choice
> for your processor.  Or better, code the checksum in assembly language.
> 
> If you can't use zero-copy receive and you have to copy the data, use a DMA
> memory-to-memory copy if your hardware supports it.  The less you touch the
> data the better.
> 
> Everything else I've done has been hardware dependent or used FPGA resources
> (e.g. internet checksum).

Thanks for the suggestions, I'll try some of them.

-- 
Regards.