RE: [lwip-users] Slow response times in Microblaze Webserver example

[jcr_alr]

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" <address@hidden>:

> 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: address@hidden
> [mailto:address@hidden On Behalf Of
> address@hidden
> 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 address@hidden:
> 
> >     
> > 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" <address@hidden>:
> > 
> > > 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: address@hidden
> > > [mailto:address@hidden On
> Behalf Of
> > > address@hidden
> > > Sent: Tuesday, September 19, 2006 5:47 AM
> > > To: address@hidden
> > > 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
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/lwip-users
> > > 
> > > 
> > > _______________________________________________
> > > lwip-users mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/lwip-users
> > > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
> > 
> 
> 
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>