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