RE: [lwip-users] 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 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
>