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

> On Wed, 2006-09-27 at 13:05 -0300, address@hidden 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>