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

[Pisano, Edward A]

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