Re: [lwip-users] Netconn vs. raw API performance
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 lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Netconn vs. raw API performance
Hi All, I'm currently testing our hardware with lwip 1.4.1, and I see a big performance difference between using Netconn API and the RAW api. For baseline I have used the LPCopen sample 'TCP echo Standalone' and 'TCP echo FreeRTOS' demo's. I have re-written the demos to connect to a server application on the laptop, The server application sends data with different package sizes and excpect the same data returned. The roundtrip is measured. The stack, in two samples, are setup as similar as possible in the lwipopt.h file. The target hardware is the same, just as the network and test PC. Nagle is dislabled. Also the low-level EMAC driver for the MCU are the same. With FreeRTOS and Netconn, the trohugput is poor with larger packages (>128 bytes). Sometimes the roundtrip for a package is mores than 2 seconds (It seems yo be in the netconn_write). Sometime it stalls, when the server application sends packages to fast after each other. With the RAW api standalone demo there are no problems at all. Good through put. I than tried to run the RAW TCP demo in FreeRTOS enviorenment. No problems here. Because the RAW TCP demo work fine, I assume the low level EMAC driver for the LPC17xx are working ok. Because the RAW TCP sample works fine wtih FreeRTOS I assume that works fine too. Any other Idea's why this? Or things I could try? Somehow the combination of LPC17xx and Netconn seems to be a bad choice.!?? (Using google I can see Im not the only one strugling with lwip and LPC17xx) I will try to updgrade my test sample with the latest lwip 2.0 to see if that somehow helps. If not, I think I will revert to using the RAW TCP in my user application and droppping Netconn API Thomas -- View this message in context: http://lwip.100.n7.nabble.com/Netconn-vs-raw-API-performance-tp27353.html Sent from the lwip-users mailing list archive at Nabble.com. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
