[lwip-users] (no subject)

[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




-----Original Message-----
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.