Re: [lwip-devel] RE: [lwip-users] httpd slow response

[Kieran Mansley]

On Mon, 2009-04-27 at 15:17 -0400, Bill Auerbach wrote:
> I think I'm not
> in the minority for wanting the highest performance possible where code size
> and available RAM are not issues.  I have made dozens of simple changes and
> increased my bandwidth over 10% over the base code. 

I first came to lwIP with the same goals: wanting high performance
without having any constraints of code size and RAM, but the attraction
of lwIP was that it was clean and simple and could be easily customised
to my needs.  The problem with trying to optimise performance is that
you can speed up one traffic pattern at the expense of another.  The
Nagle algorithm that started this discussion is a good example: for bulk
transfers Nagle can help a lot, but in your case with ping-pong style
traffic it harms performance.  I think therefore that by keeping the
code clean and simple we serve both goals well.  Those who need to
optimise for code size and RAM can do so.  Those that need to optimise
for performance can do so.  I'd encourage everyone to share their
improvements, but not all will make it back into the core stack.  I am
therefore happy to continue with the project's goals as they stand.  

> Can we/should we add a task for an lwIP test application that can be used on
> systems to test performance using some defacto standard program that can be
> run on Windows or Linux talking to the lwIP device?  Conditional compile for
> Raw API and Sockets would be nice I think. I know cross-comparisons can't be
> made, but at least there will be information on what performance has been
> seen.  When we go to "sockets 2", having this would give us a program to
> compare the 2 implementations.

With the sockets API we should just be able to use an existing micro-
benchmark, such as ttcp.  For the raw API we'd have to customise
something, but that would be a good starting point rather than writing
another micro-benchmark from scratch.

Kieran