Slow response times in Microblaze Webserver example

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Slow response times in Microblaze Webserver example

jcr_alr
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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Slow response times in Microblaze Webserver example

Pisano, Edward A
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: lwip-users-bounces+edward.pisano=[hidden email]
[mailto:lwip-users-bounces+edward.pisano=[hidden email]] On Behalf Of
[hidden email]
Sent: Tuesday, September 19, 2006 5:47 AM
To: [hidden email]
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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Slow response times in Microblaze Webserver example

jcr_alr
   
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" <[hidden email]>:

> 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: lwip-users-bounces+edward.pisano=[hidden email]
> [mailto:lwip-users-bounces+edward.pisano=[hidden email]] On Behalf Of
> [hidden email]
> Sent: Tuesday, September 19, 2006 5:47 AM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Slow response times in Microblaze Webserver example

jcr_alr
I found using windump that the delta time between the client receiving the last
ACK in the initial handshake and sending the following write command was very
short (less that a microsecond?). The Microblaze server missed this write,
which was resent some 2.5 - 3 seconds later, when the server had not received a
response to the first write. I added a 30 millisec delay between the client's
connect function and the following write function - this seems to have cleared
up the problem in that the server now always responds promptly.

I do not understand why such a long delay is necessary. This is the first time
I have used lwIP so I am still trying to follow its operation with the help of
the Xilinx and lwIP.pdf documentation. Is there any other documentation
available - there was some mention in the archives of send flow charts, for
instance.  My next step is for the server using lwIP to send much larger data
than the few bytes sent now. The current data acquisition application has to
send 2 - 3 Kbytes every 100 millisecs or so.

For Xilinx people, there was mention in the archives of some speed improvements
being made. Would these improvements have been implemented in my version (
8.1.02i EDK_1.20.4 + 1)? If not when do you expect to make them available.



Quoting [hidden email]:

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





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: Slow response times in Microblaze Webserver example

jcr_alr
In reply to this post by jcr_alr
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 [hidden email]:

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





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: 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: lwip-users-bounces+edward.pisano=[hidden email]
[mailto:lwip-users-bounces+edward.pisano=[hidden email]] On Behalf Of
[hidden email]
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 [hidden email]:

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





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: 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" <[hidden email]>:

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





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

Sathya Thammanur
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, [hidden email] <[hidden email]> 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" <[hidden email]>:

> 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=[hidden email]
> [mailto:[hidden email]] On Behalf Of
> [hidden email]
> 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 [hidden email]:
>
> >
> > 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" <[hidden email]>:
> >
> > > 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: lwip-users-bounces+edward.pisano=[hidden email]
> > > [mailto:[hidden email]] On
> Behalf Of
> > > [hidden email]
> > > Sent: Tuesday, September 19, 2006 5:47 AM
> > > To: [hidden email]
> > > 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
> > > [hidden email]
> > > <a href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://lists.nongnu.org/mailman/listinfo/lwip-users
> > >
> > >
> > > _______________________________________________
> > > lwip-users mailing list
> > > [hidden email]
> > > <a href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.nongnu.org/mailman/listinfo/lwip-users
> > >
> >
> >
> >
> >
> >
> > _______________________________________________
> > lwip-users mailing list
> > [hidden email]
> > <a href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://lists.nongnu.org/mailman/listinfo/lwip-users
> >
>
>
>
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> <a href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> <a href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://lists.nongnu.org/mailman/listinfo/lwip-users
>





_______________________________________________
lwip-users mailing list
[hidden email]
<a href="http://lists.nongnu.org/mailman/listinfo/lwip-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

jcr_alr
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 <[hidden email]>:

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





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

Sathya Thammanur
Hi John,
TCP/IP stacks involve reading of headers and fields within protocol header. All of these are implemented as shifts and multiplies. Without hardware support, these operations are implemented in software which tends to slow down the processor. Hence barrel shifts and multiplier hardware is important to get good performance.

Sathya


On 9/25/06, [hidden email] <[hidden email]> wrote:
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 <[hidden email]>:

> 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, [hidden email] <[hidden email]> 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" <[hidden email]>:
> >
> > > 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= [hidden email]
> > > [mailto:[hidden email]] On Behalf Of
> > > [hidden email]

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





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

jcr_alr
Hi Sathya,

Thanks for your last message.

My efforts to get Microblaze lwIP working seem to be getting nowhere. I
implemented the barrel shifter and multiplier options, both together and
separately but in all three cases, there did not seem to any difference in the
times read by windump. For some reason, the Microblaze is sending RSTs to the
client thus

064131 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: S 1324574079:1324574079(0)
win 65535 <mss 1460,nop,nop,sackOK>
025123 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: S 74879:74879(0) ack
1324574080 win 16384 <mss 1460>
000024 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1 win 65535
013976 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: P 1:31(30) ack 1 win 65535
032930 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16354
027001 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16384
033323 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: P 1:1261(1260) ack 31 win
16384
015320 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: F 1261:1261(0) ack 31 win
16384
000042 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1262 win 64275
000098 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: F 31:31(0) ack 1262 win 64275
171178 IP IBM-F3860BD49B6.1671 > 192.168.0.200.80: F 2601444881:2601444881(0)
ack 62994 win 64275
018375 IP 192.168.0.200.80 > IBM-F3860BD49B6.1671: R 2:2(0) ack 1 win 16384
181919 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: F 2886869572:2886869572(0)
ack 72265 win 64275
017283 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win 16384
000060 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: . ack 1 win 64275
026673 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win 16384
356558 IP IBM-F3860BD49B6.1662 > 192.168.0.200.80: F 2269257405:2269257405(0)
ack 47843 win 64275
016779 IP 192.168.0.200.80 > IBM-F3860BD49B6.1662: R 2:2(0) ack 1 win 16384

The server, Microblaze, sends the requested data then the FIN to which the
client, IBM, responds with an ack, then two FINs. Should there be an
acknowledgement of the first FIN by the server? Is the server getting confused
and then sending the RST?

Is there any example code I can use on the S3e starter board. I did notice the  
webserver example did also seem to be rather erratic in terms of its response
times. I used the example code simply modifying the processGet function to
return a set of numeric data as I have written in the earlier emails.

I really would appreciate any help as I seem to going around in circles now.

John Robbins.




Quoting Sathya Thammanur <[hidden email]>:

> Hi John,
> TCP/IP stacks involve reading of headers and fields within protocol header.
> All of these are implemented as shifts and multiplies. Without hardware
> support, these operations are implemented in software which tends to slow
> down the processor. Hence barrel shifts and multiplier hardware is important
> to get good performance.
>
> Sathya
>
>
> On 9/25/06, [hidden email] <[hidden email]> wrote:
> >
> > 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 <[hidden email]>:
> >
> > > 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, [hidden email] <[hidden email]> 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" <[hidden email]>:
> > > >
> > > > > 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= [hidden email]
> > > > > [mailto:lwip-users-bounces+edward.pisano=[hidden email]] On
> > Behalf Of
> > > > > [hidden email]
> > > > > 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.
> > _______________________________________________
> > lwip-users mailing list
> > [hidden email]
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
> >
>





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

Kieran Mansley
On Wed, 2006-09-27 at 13:05 -0300, [hidden email] wrote:

> 064131 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: S 1324574079:1324574079(0)
> win 65535 <mss 1460,nop,nop,sackOK>
> 025123 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: S 74879:74879(0) ack
> 1324574080 win 16384 <mss 1460>
> 000024 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1 win 65535
> 013976 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: P 1:31(30) ack 1 win 65535
> 032930 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16354
> 027001 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16384
> 033323 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: P 1:1261(1260) ack 31 win
> 16384
> 015320 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: F 1261:1261(0) ack 31 win
> 16384
> 000042 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1262 win 64275
> 000098 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: F 31:31(0) ack 1262 win 64275
> 171178 IP IBM-F3860BD49B6.1671 > 192.168.0.200.80: F 2601444881:2601444881(0)
> ack 62994 win 64275
> 018375 IP 192.168.0.200.80 > IBM-F3860BD49B6.1671: R 2:2(0) ack 1 win 16384
> 181919 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: F 2886869572:2886869572(0)
> ack 72265 win 64275
> 017283 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win 16384
> 000060 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: . ack 1 win 64275
> 026673 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win 16384
> 356558 IP IBM-F3860BD49B6.1662 > 192.168.0.200.80: F 2269257405:2269257405(0)
> ack 47843 win 64275
> 016779 IP 192.168.0.200.80 > IBM-F3860BD49B6.1662: R 2:2(0) ack 1 win 16384
>
> The server, Microblaze, sends the requested data then the FIN to which the
> client, IBM, responds with an ack, then two FINs. Should there be an
> acknowledgement of the first FIN by the server? Is the server getting confused
> and then sending the RST?

I can't comment on any of the performance issues you have with the
hardware as that's outside my field of expertise but the above TCP trace
I can help with.

The server is acknowledging the first FIN correctly - that's the packet
#9 in the above trace (line starts 000042).

The two FINs subsequently sent by the IBM are for two different
connections - one is from port 1678 (which seems to be the connection
you're discussing, and this is normal and in response to the FIN sent by
the server) and one is from port 1671 (which doesn't have any other
traffic in the above trace).  The Microblaze doesn't seem to know about
the 1671 port connection either as it sends a RST in response.  This is
the most likely reason for the RST anyway - if it receives a packet for
a connection it doesn't know about, a RST is the expected behaviour.

Hope that helps

Kieran



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

jcr_alr
Hi Kieran,

Thanks for the help. I had not noticed the change in connection number. I had
tried various combinations of disconnect/shutdown after each data transfer on
the client end (XP). With no disconnect/shutdown, the system seems to work for
a few seconds, then a lot of RSTs, an occasional UDP request and then a few
good transfers.

This is all when the client is connected to the Microblaze server. I have just
reconnected the Netburner server and it runs like clockwork (and much faster)
against the same client. Each time the client starts a new transaction a new
port number is used but there are no other changes. The Netburner uses a
Coldfire 5272, with uCos and an Etherenet stack that I think was written by one
of the Netburner founders but I am not sure.

I really do hope that I can get some help from Xilinx as I am running out of
ideas to try.

John Robbins


Quoting Kieran Mansley <[hidden email]>:

> On Wed, 2006-09-27 at 13:05 -0300, [hidden email] wrote:
>
> > 064131 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: S
> 1324574079:1324574079(0)
> > win 65535 <mss 1460,nop,nop,sackOK>
> > 025123 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: S 74879:74879(0) ack
> > 1324574080 win 16384 <mss 1460>
> > 000024 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1 win 65535
> > 013976 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: P 1:31(30) ack 1 win
> 65535
> > 032930 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16354
> > 027001 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16384
> > 033323 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: P 1:1261(1260) ack 31
> win
> > 16384
> > 015320 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: F 1261:1261(0) ack 31
> win
> > 16384
> > 000042 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1262 win 64275
> > 000098 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: F 31:31(0) ack 1262 win
> 64275
> > 171178 IP IBM-F3860BD49B6.1671 > 192.168.0.200.80: F
> 2601444881:2601444881(0)
> > ack 62994 win 64275
> > 018375 IP 192.168.0.200.80 > IBM-F3860BD49B6.1671: R 2:2(0) ack 1 win
> 16384
> > 181919 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: F
> 2886869572:2886869572(0)
> > ack 72265 win 64275
> > 017283 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win
> 16384
> > 000060 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: . ack 1 win 64275
> > 026673 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win
> 16384
> > 356558 IP IBM-F3860BD49B6.1662 > 192.168.0.200.80: F
> 2269257405:2269257405(0)
> > ack 47843 win 64275
> > 016779 IP 192.168.0.200.80 > IBM-F3860BD49B6.1662: R 2:2(0) ack 1 win
> 16384
> >
> > The server, Microblaze, sends the requested data then the FIN to which the
>
> > client, IBM, responds with an ack, then two FINs. Should there be an
> > acknowledgement of the first FIN by the server? Is the server getting
> confused
> > and then sending the RST?
>
> I can't comment on any of the performance issues you have with the
> hardware as that's outside my field of expertise but the above TCP trace
> I can help with.
>
> The server is acknowledging the first FIN correctly - that's the packet
> #9 in the above trace (line starts 000042).
>
> The two FINs subsequently sent by the IBM are for two different
> connections - one is from port 1678 (which seems to be the connection
> you're discussing, and this is normal and in response to the FIN sent by
> the server) and one is from port 1671 (which doesn't have any other
> traffic in the above trace).  The Microblaze doesn't seem to know about
> the 1671 port connection either as it sends a RST in response.  This is
> the most likely reason for the RST anyway - if it receives a packet for
> a connection it doesn't know about, a RST is the expected behaviour.
>
> Hope that helps
>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

jcr_alr
In reply to this post by Kieran Mansley
I am making some progress with the slow ping response times. I realised that
part of the problem was the use of SCHED_RR with a systmr_interval value of 10.
With the two threads used in responding to the ping request, these delays
accounted for most of the observed value. Setting the systmr_interval parameter
to 1 (the minimum?)reduced the ping times to 3 - 4 millisecs. I instrumented
the emac and lwip libraries and from the observed timings it seems that the
response time would be much better running under SCHED_PRIO.

At the present under SCHED_PRIO, I cannot get past lwip_init() in xemacif.c.
With gdb it looks as if the thread lwip_init_proper is never created so that
the variable lwp_init_proper_done is never set. It seems that something strange
is happening in the previous block where there semaphores, messageboxes etc are
setup, which probably means that I have missed setting up the xilkernel/lwip
parameters properly for use under SCHED_PRIO.

Any input again would be most welcome.

John Robbins



 
Quoting Kieran Mansley <[hidden email]>:

> On Wed, 2006-09-27 at 13:05 -0300, [hidden email] wrote:
>
> > 064131 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: S
> 1324574079:1324574079(0)
> > win 65535 <mss 1460,nop,nop,sackOK>
> > 025123 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: S 74879:74879(0) ack
> > 1324574080 win 16384 <mss 1460>
> > 000024 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1 win 65535
> > 013976 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: P 1:31(30) ack 1 win
> 65535
> > 032930 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16354
> > 027001 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16384
> > 033323 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: P 1:1261(1260) ack 31
> win
> > 16384
> > 015320 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: F 1261:1261(0) ack 31
> win
> > 16384
> > 000042 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1262 win 64275
> > 000098 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: F 31:31(0) ack 1262 win
> 64275
> > 171178 IP IBM-F3860BD49B6.1671 > 192.168.0.200.80: F
> 2601444881:2601444881(0)
> > ack 62994 win 64275
> > 018375 IP 192.168.0.200.80 > IBM-F3860BD49B6.1671: R 2:2(0) ack 1 win
> 16384
> > 181919 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: F
> 2886869572:2886869572(0)
> > ack 72265 win 64275
> > 017283 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win
> 16384
> > 000060 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: . ack 1 win 64275
> > 026673 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win
> 16384
> > 356558 IP IBM-F3860BD49B6.1662 > 192.168.0.200.80: F
> 2269257405:2269257405(0)
> > ack 47843 win 64275
> > 016779 IP 192.168.0.200.80 > IBM-F3860BD49B6.1662: R 2:2(0) ack 1 win
> 16384
> >
> > The server, Microblaze, sends the requested data then the FIN to which the
>
> > client, IBM, responds with an ack, then two FINs. Should there be an
> > acknowledgement of the first FIN by the server? Is the server getting
> confused
> > and then sending the RST?
>
> I can't comment on any of the performance issues you have with the
> hardware as that's outside my field of expertise but the above TCP trace
> I can help with.
>
> The server is acknowledging the first FIN correctly - that's the packet
> #9 in the above trace (line starts 000042).
>
> The two FINs subsequently sent by the IBM are for two different
> connections - one is from port 1678 (which seems to be the connection
> you're discussing, and this is normal and in response to the FIN sent by
> the server) and one is from port 1671 (which doesn't have any other
> traffic in the above trace).  The Microblaze doesn't seem to know about
> the 1671 port connection either as it sends a RST in response.  This is
> the most likely reason for the RST anyway - if it receives a packet for
> a connection it doesn't know about, a RST is the expected behaviour.
>
> Hope that helps
>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

Sathya Thammanur
The Priority scheduler working with lwIP had fixes done and should be available with EDK8.2.1i release.

Hope this helps

Sathya

On 10/18/06, [hidden email] <[hidden email]> wrote:
I am making some progress with the slow ping response times. I realised that
part of the problem was the use of SCHED_RR with a systmr_interval value of 10.
With the two threads used in responding to the ping request, these delays
accounted for most of the observed value. Setting the systmr_interval parameter
to 1 (the minimum?)reduced the ping times to 3 - 4 millisecs. I instrumented
the emac and lwip libraries and from the observed timings it seems that the
response time would be much better running under SCHED_PRIO.

At the present under SCHED_PRIO, I cannot get past lwip_init() in xemacif.c .
With gdb it looks as if the thread lwip_init_proper is never created so that
the variable lwp_init_proper_done is never set. It seems that something strange
is happening in the previous block where there semaphores, messageboxes etc are
setup, which probably means that I have missed setting up the xilkernel/lwip
parameters properly for use under SCHED_PRIO.

Any input again would be most welcome.

John Robbins




Quoting Kieran Mansley < [hidden email]>:

> On Wed, 2006-09-27 at 13:05 -0300, [hidden email] wrote:
>
> > 064131 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: S
> 1324574079:1324574079(0)
> > win 65535 <mss 1460,nop,nop,sackOK>
> > 025123 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: S 74879:74879(0) ack
> > 1324574080 win 16384 <mss 1460>
> > 000024 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1 win 65535
> > 013976 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: P 1:31(30) ack 1 win
> 65535
> > 032930 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16354
> > 027001 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16384
> > 033323 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: P 1:1261(1260) ack 31
> win
> > 16384
> > 015320 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: F 1261:1261(0) ack 31
> win
> > 16384
> > 000042 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1262 win 64275
> > 000098 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: F 31:31(0) ack 1262 win
> 64275
> > 171178 IP IBM-F3860BD49B6.1671 > 192.168.0.200.80: F
> 2601444881:2601444881(0)
> > ack 62994 win 64275
> > 018375 IP 192.168.0.200.80 > IBM-F3860BD49B6.1671: R 2:2(0) ack 1 win
> 16384
> > 181919 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: F
> 2886869572:2886869572(0)
> > ack 72265 win 64275
> > 017283 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win
> 16384
> > 000060 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: . ack 1 win 64275
> > 026673 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win
> 16384
> > 356558 IP IBM-F3860BD49B6.1662 > 192.168.0.200.80: F
> 2269257405:2269257405(0)
> > ack 47843 win 64275
> > 016779 IP 192.168.0.200.80 > IBM-F3860BD49B6.1662: R 2:2(0) ack 1 win
> 16384
> >
> > The server, Microblaze, sends the requested data then the FIN to which the
>
> > client, IBM, responds with an ack, then two FINs. Should there be an
> > acknowledgement of the first FIN by the server? Is the server getting
> confused
> > and then sending the RST?
>
> I can't comment on any of the performance issues you have with the
> hardware as that's outside my field of expertise but the above TCP trace
> I can help with.
>
> The server is acknowledging the first FIN correctly - that's the packet
> #9 in the above trace (line starts 000042).
>
> The two FINs subsequently sent by the IBM are for two different
> connections - one is from port 1678 (which seems to be the connection
> you're discussing, and this is normal and in response to the FIN sent by
> the server) and one is from port 1671 (which doesn't have any other
> traffic in the above trace).  The Microblaze doesn't seem to know about
> the 1671 port connection either as it sends a RST in response.  This is
> the most likely reason for the RST anyway - if it receives a packet for
> a connection it doesn't know about, a RST is the expected behaviour.
>
> Hope that helps
>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Slow response times in Microblaze Webserver example

jcr_alr
Hi Sathya,

Thanks for your message. I apologise for taking so long to reply but was away
from an internet connection. I have been working with lwip set to PRIO and have
succeeded in getting lwip to work in SCHED_PRIO mode, at least to a
certain extent. In sys_arch.c I added an array,
 
pthread_attr_t attr_prio[SYS_THREAD_MAX].

In sys_thread_new(void (* function)(void *arg), void *arg, int prio)

#if SCHED_TYPE == SCHED_PRIO
        attr_prio[i].schedparam.sched_priority = prio;
#endif

This allowed lwip_init_proper() to run. I commented out while (1);
at the end of the function to allow it to exit.

Now ping does work, although the response times are still quite poor, 5 - 6 ms.

Part of the delay, 1.6 ms, seems to be in tcpip_input() (tcpip.c) across the
call to memp_malloc(). This function sets a mutex which is released
after the memory is obtained. I am still trying to understand the mutex code
which seems to be sort of time-quantised (1 ms?).

Any help would be appreciated. If your new lwip and xilkernel is available, I
should really like to use it. I don't at this moment really want to switch to
8.2 as I have come to trust 8.1.02 quite well.

John Robbins


Quoting Sathya Thammanur <[hidden email]>:

> The Priority scheduler working with lwIP had fixes done and should be
> available with EDK8.2.1i release.
>
> Hope this helps
>
> Sathya
>
> On 10/18/06, [hidden email] <[hidden email]> wrote:
> >
> > I am making some progress with the slow ping response times. I realised
> > that
> > part of the problem was the use of SCHED_RR with a systmr_interval value
> > of 10.
> > With the two threads used in responding to the ping request, these delays
> > accounted for most of the observed value. Setting the systmr_interval
> > parameter
> > to 1 (the minimum?)reduced the ping times to 3 - 4 millisecs. I
> > instrumented
> > the emac and lwip libraries and from the observed timings it seems that
> > the
> > response time would be much better running under SCHED_PRIO.
> >
> > At the present under SCHED_PRIO, I cannot get past lwip_init() in
> > xemacif.c.
> > With gdb it looks as if the thread lwip_init_proper is never created so
> > that
> > the variable lwp_init_proper_done is never set. It seems that something
> > strange
> > is happening in the previous block where there semaphores, messageboxes
> > etc are
> > setup, which probably means that I have missed setting up the
> > xilkernel/lwip
> > parameters properly for use under SCHED_PRIO.
> >
> > Any input again would be most welcome.
> >
> > John Robbins
> >
> >
> >
> >
>



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users