Re: [lwip-users] 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 <address@hidden>:

> 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, address@hidden <address@hidden> 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 <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.
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/lwip-users
> >
>