Hi Sathya, Thanks for the fast response. I will certainly try all your suggestions before struggling with RAW_API.
I am really surprised about your item 2. How/where are the barrel shifter and multiplier used for lwIP. John. Quoting Sathya Thammanur <[EMAIL PROTECTED]>: > Hi John, > As Ed mentioned, the following hardware settings would really help in > improving the performance: > > 1. Cache size on I and D sides - The 66Mhz system on spartan can have > upto 8k of I and D caches > 2. Enabling the barrel shifter and multiplier options on MicroBlaze. > This is key. > 3. Set the compiler optimization to -O3 with a -DNDEBUG switch to > better optimize the drivers > 4. For Transmit side, the message size of 2-4k was optimal > > When using Sockets mode, it was also seen that with priority scheduling > enabled on xilkernel, the performance did improve. However, as you said > earlier this is available in EDK8.2.1i (SP1). The RAW API improvements > should be available in 8.1i release of EDK itself. > > Sathya > > On 9/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Hi Ed, > > > > Thanks again. I guess I will have to bite the bullet and start an > > implementation of the RAW_API. I really did not think that my really quite > > > > modest requirements would not be met by the sockets version. > > > > John Robbins > > > > > > > > Quoting "Pisano, Edward A" <[EMAIL PROTECTED]>: > > > > > Hi John, > > > In experimenting with lwIP on MicroBlaze, I saw some significant > > > performance improvements when I setup and enabled the data cache and > > > instruction cache. Also, there are some other architectural things that > > > can be done such as using the multi-channel memory (mch_opb_ddr) and > > > placing certain structures that are accessed frequently, but run a small > > > risk of be flushed from cache occasionally, into the dlmb section. I've > > > > > been told the LMB is almost as fast as cache. > > > > > > In this environment with SOCKETS_API, I was to delay 10ms between 1400 > > > byte UDP datagrams transmitted from my laptop and echo'd back by the > > > Spartan 3E before seeing any packet loss. > > > > > > Of late, I've extended the experiments to using the lwIP RAW_API. It is > > > much, much faster. I've reduced the delay between UDP datagrams as low > > > as 2ms for small file (50KB) echo back. In RAW_API, there's no > > > xilkernel and you must take care of lwIP memory management yourself. > > > > > > Regards, > > > Ed > > > -----Original Message----- > > > From: lwip-users-bounces+edward.pisano= [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > [EMAIL PROTECTED] > > > Sent: Sunday, September 24, 2006 6:40 PM > > > To: Mailing list for lwIP users > > > Subject: RE: [lwip-users] Slow response times in Microblaze Webserver > > > example > > > > > > I compared timing for the same data transfer using a Netburner SB72 card > > > > > > > > (Coldfire MCF5272 @ 66MHz) with the Microblaze (Spartan3e starter kit @ > > > 50MHz) > > > as the server. The client at the end of a short crossover cable was a > > > newish > > > IBM laptop running XP and reporting a 100bpsconnection, the code being > > > written > > > in C++ for .Net. In response to a GET request the server sent 1260 bytes > > > > > > (actually 315 integers). To see the output change in the client but > > > without > > > distorting the lwIP timing, the server program changed only the first > > > and last > > > integer values. > > > > > > The following lines show one transfer for each system. The request > > > period was > > > 500 millisecond. The first delta time therefore is the difference > > > between this > > > period and the time required for the previous transfer. > > > > > > Netburner > > > > > > > > > 460385 IP IBM-F3860BD49B6.1081 > 192.168.0.200.80: > > > S > > > 1367389610:1367389610(0) win 65535 <mss > > > "1460,nop,nop,sackOK>" > > > 657 IP 192.168.0.200.80 > IBM-F3860BD49B6.1081: > > > S > > > 19071019:19071019(0) ack 1367389611 win 0 > > > <mss > > > "1460,nop,nop,nop,eol>" > > > 40 IP IBM-F3860BD49B6.1081 > 192.168.0.200.80: > > > . > > > ack 1 win 65535 > > > 926 IP 192.168.0.200.80 > IBM-F3860BD49B6.1081: > > > . > > > ack 1 win 4644 > > > 35211 IP IBM-F3860BD49B6.1081 > 192.168.0.200.80: > > > P > > > 1:31(30) ack 1 win 65535 > > > 2252 IP 192.168.0.200.80 > IBM-F3860BD49B6.1081: > > > P > > > 1:1261(1260) ack 31 win 4614 > > > 31 IP 192.168.0.200.80 > IBM-F3860BD49B6.1081: > > > F > > > 1261:1261(0) ack 31 win 0 > > > 31 IP IBM-F3860BD49B6.1081 > 192.168.0.200.80: > > > . > > > ack 1262 win 64275 > > > 39148 > > > > > > > > > Microblaze > > > > > > > > > 349914 IP IBM-F3860BD49B6.1147 > 192.168.0.200.80: > > > S > > > 3416876235:3416876235(0) win 65535 <mss > > > "1460,nop,nop,sackOK>" > > > 21994 IP 192.168.0.200.80 > IBM-F3860BD49B6.1147: > > > S > > > 32027:32027(0) ack 3416876236 win 16384 <mss > > > 1460> > > > 50 IP IBM-F3860BD49B6.1147 > 192.168.0.200.80: > > > . > > > ack 1 win 65535 > > > 35108 IP IBM-F3860BD49B6.1147 > 192.168.0.200.80: > > > P > > > 1:31(30) ack 1 win 65535 > > > 20632 IP 192.168.0.200.80 > IBM-F3860BD49B6.1147: > > > . > > > ack 31 win 16354 > > > 25924 IP 192.168.0.200.80 > IBM-F3860BD49B6.1147: > > > . > > > ack 31 win 16384 > > > 32843 IP 192.168.0.200.80 > IBM-F3860BD49B6.1147: > > > P > > > 1:1261(1260) ack 31 win 16384 > > > 15552 IP 192.168.0.200.80 > IBM-F3860BD49B6.1147: > > > F > > > 1261:1261(0) ack 31 win 16384 > > > 52 IP IBM-F3860BD49B6.1147 > 192.168.0.200.80: > > > . > > > ack 1262 win 64275 > > > 152155 > > > > > > > > > The data transfer time for the Microblaze (33 msec) is more than ten > > > times > > > slower than the Netburner (2.2 msec). The overall time for the complete > > > transaction for the Microblaze was 152 msec against the Netburner's 39 > > > msecs. > > > > > > I am sure I must be doing something wrong. These results are really most > > > > > > disappointing as I was hoping to replace the Netburner with a Microblaze > > > > > based > > > solution for our new DAQ system. > > > > > > I am using the same xilkernel and lwIP settings as in the Webserver > > > example for > > > the S3e board. Are there any different optimisations I should be using? > > > > > > Any help would be most appreciated. > > > > > > John Robbins. > > > > > > > > > Quoting [EMAIL PROTECTED]: > > > > > > > > > > > Hi Ed, > > > > > > > > Thanks for fast response. > > > > > > > > I removed the xil_printf messages and turned off LWIP_DEBUG. The Ping > > > time > > > > dropped from 215 to 16 millisecs. > > > > > > > > However when I run the GET request the time spent in the read function > > > is > > > > still > > > > 2820 millisecs except for the very first time when both the client and > > > server > > > > > > > > programs are loaded and run, then the time is 26 millisecs. Restarting > > > either > > > > > > > > the client or server without restarting the other still results in the > > > long > > > > delay time. The other lwIP functions called by the Webserver code(eg > > > accept, > > > > > > > > write) seem to be fast. > > > > > > > > Without the RS232 messages, the short response time when both server > > > and > > > > client > > > > are restarted seems to be very consistent whereas before the short > > > response > > > > time was seen only under these conditions but then not always. > > > > > > > > Any more thoughts on resolving this problem would be most appreciated. > > > > > > > > John Robbins > > > > > > > > Quoting "Pisano, Edward A" <[EMAIL PROTECTED]>: > > > > > > > > > Hi John, > > > > > I had seen similar slow response with the WebServer example. It > > > turned > > > > > out to be the debug output messages. The RS-232 output has a > > > > > significant slowing effect on lwIP. In my case, ping replies were > > > > > taking 1700ms to 3400ms on the Spartan 3E. I turned off LWIP_DEBUG > > > > > and > > > > > commented out my own xil_print() statements. Ping replies quickly > > > > > dropped to 17ms-25ms. > > > > > > > > > > Regards, > > > > > Ed > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED] ] On > > > Behalf Of > > > > > [EMAIL PROTECTED] > > > > > Sent: Tuesday, September 19, 2006 5:47 AM > > > > > To: [email protected] > > > > > Subject: [lwip-users] Slow response times in Microblaze Webserver > > > > > example > > > > > > > > > > Dear All, > > > > > > > > > > I have been testing a program modified from the Webserver example > > > for > > > > > the > > > > > Xilinx Spartan3e Starter Kit. A client application on a PC connected > > > to > > > > > the > > > > > board via a crossover cable issues a GET command, to which the > > > server > > > > > should > > > > > respond with a short string, about 50 bytes. > > > > > > > > > > The problem that I am finding is that, although the response is > > > > > occasionally > > > > > very fast, 99% of the time the response may take several seconds. > > > Since > > > > > my > > > > > eventual application is a fairly fast data acquisition requirement, > > > this > > > > > is a > > > > > problem. > > > > > > > > > > To debug this, I first removed the mfs part of the Webserver > > > example, > > > > > then > > > > > added GPIO calls to the LEDs before and after the read function in > > > > > processConnection. Using an Ant8 logic analyser, I found that the > > > time > > > > > needed > > > > > in this function was very occasionally 30 - 40 millisecs but almost > > > > > always > > > > > around 2900 millisecs. > > > > > > > > > > Using gdb, I traced the delay to the call in netconn_recv() to > > > > > sys_mbox_fetch() > > > > > which blocks for 3 seconds, then all the rest of code executes as > > > > > expected. The > > > > > fast response seems only to occur the first time both the client and > > > > > server are > > > > > run. > > > > > > > > > > In XPS I selected the debug output option, set the rs232 speed to > > > 115kbs > > > > > and > > > > > directed the output to a file. > > > > > > > > > > During the block period the system appears to emit at least > > > > > six "tcp_slowtmr:procssing active pcb messages" interspersed with > > > some > > > > > timeout > > > > > messages. > > > > > > > > > > In case I was doing something wrong in the client code, I used the > > > same > > > > > program > > > > > to talk to a Netburner card, issuing the same response to a GET > > > request. > > > > > The > > > > > delays were of the order of a few millisecs. > > > > > > > > > > So I am sure I am doing something stupid in the server code and > > > would > > > > > really > > > > > appreciate any help. > > > > > > > > > > JOhn Robbins. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
