Netconn has more overhead than the RAW API. In scenarios where the eth pipe is faster than the micro, this extra overhead means extra latency and so less thruput.
However, 2 seconds rtt is, how can I say it, a bit way too much ?
Having "problems" with more than 128 bytes per message is another indication that something in your port, or your netconn application, is not correct. If you suspect that netconn_write() takes too long, why don't you move a pin and time it ? Perhaps you've found the priority bug again ? Try searching the list, or perhaps the task is scheduled too spaced apart ?

Your driver might be OK, and the port, since the RAW API apps seem to work OK, or it could just be that you think they run OK and they don't. A TCP echo can run smoothly on a really broken port, I've seen that, try something more real like a web server, for 1.4.1 it is in the contrib tree. Furthermore, if you will use an example, throw away vendor demos and get it off the contrib tree. For 2.0.0 the server is an app in the main tree.

PS: people is not struggling with lwIP and LPCs, they are struggling with ports and drivers not following lwIP guidelines.

lwip-users mailing list

Reply via email to