I am mainly concerned about transmitting at at least 150Mbits/sec. The speeds i'm refering to are provided by xilinx in the xapp1026.pdf document they provide for using lwip on a xilinx board. They claim tcp in raw mode performs at 140Mbits/sec. I assume UDP is faster, but i'm no where near the 140 right now.
On Wed, Sep 23, 2009 at 5:03 PM, Bill Auerbach <[email protected]> wrote: > Which direction? Improving sending and improving receiving are 2 different > problems. They overlap some, but the focus is different. > > Something's not right if offloading was used and it didn't help - it should > double to quadruple the speed. Try turning off CHECKSUM_GEN_UDP and > CHECKSUM_CHECK_UDP. Offloading or doing the checksum in hardware is one > critical item. As is optimizing memory and memory copies (using a DMA > memcpy over the standard C memcpy is huge). Using zero-copy drivers for > sending and/or receiving is huge (because you're not copying). > > I spent 2+ months optimizing lwIP - at first for TCP, which although I > doubled, wasn't nearly fast enough. We switched to UDP and proved the speed > was adequate to move forward. Then I wrote a reliable UDP protocol (not > hard to do, but had to be done since we can't lose data). Some of my > optimizations were submitted but some may be target dependent (i.e. little > endian improvements or specific to my variant of GCC). I've pushed the past > 2 years for better performance and I realize resources are limited to > support it as well as it's not a top priority for the goals of lwIP (Light > Weight being the key words here). For most users I suspect what we have is > fast enough - plus it's a very good and reliable implementation of TCP/IP. > > Documented speed has a lot to do with the platform. On a high speed PowerPC > with assembly internet checksum and DMA memory copies, lwIP met our needs > without any other changes or optimizations except a low level UDP/ICMP/ARP > packet filter (in low_level_input) while in our "high bandwidth" mode. We > didn't have to do this - I just didn't want a UDP or ICMP burst to disrupt > system timing. On a lower speed FPGA project, a lot of effort was put into > lwIP and supporting code and the FPGA to meet our goals. > > Bill > > > >>-----Original Message----- >>From: [email protected] >>[mailto:[email protected]] On >>Behalf Of bobbyb >>Sent: Wednesday, September 23, 2009 4:02 PM >>To: [email protected] >>Subject: [lwip-users] How to optimize raw UDP performance >> >> >>What are some good techniques for improving UDP performance in raw mode. >>Right now i'm getting approximately 82Mbits/sec. I would like to >>increase >>that to 150+ Mbits/sec which should be possible according to the >>documentation. I've tried increasing various buffer/memory sizes with >>very >>small effects. I also setup checksum offloading which surprisingly had >>no >>effect on performance. >> >>Does anyone know any other techniques worth trying? Why is the >>documented >>speed so much higher than what I'm getting? >> >>Thanks >>-- >>View this message in context: http://www.nabble.com/How-to-optimize-raw- >>UDP-performance-tp25531280p25531280.html >>Sent from the lwip-users mailing list archive at Nabble.com. >> >> >> >>_______________________________________________ >>lwip-users mailing list >>[email protected] >>http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
