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

[Bill Auerbach]

Cross-posted to lwip-devel since it's relevant.

>I guess this is not really a good example, then: tcp_output is called
>from tcp_in.c after calling the receive callback, so in this case, there
>is no difference. But in general, tcp_enqueue really only enqueues and
>does *not* output, so if you don't call it, data might never get sent.

A lot of people start with this, or use it as is, for a basic WEB server.
I'm not complaining - it does work and shows the callback concept.

>tcp_outupt *was* a "send now - everything you have, even if it is a very
>small packet" and was called by the sequential APIs only if there was
>enough data was enqueued (that was the nagle algorithm - only for
>netconn/socket API). However, this lead to bad throughput with the raw
>API since it did not implement the nagle algorithm.

This is a bit funny in an odd way because I had to disable Nagle to make
performance better with Raw API.  For me, performance meant send a command
down with data and get a short response back ASAP.

One thing I wonder - I see more posts asking about the performance of lwIP
or wanting to increase lwIP performance.  Many more than I see for posts
wanting to run on a small processor with limited resources.  Any chance you
developers can reassess the goals that with times changing for embedded
processor choices since lwIP was conceived that perhaps performance is
gaining ground or surpassing the original goals of lwIP?  There are now
32-bit processors in the same price range as 8-bit processors were 8 years
ago.  Yes, I admit that this question is self-serving, but 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.  Some of it included
also reducing code (i.e. the macro replacements I sent to you) and others
were processor dependent (but also applicable to other processors).

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.

Bill