Re: [lwip-users] Slow response times in Microblaze Webserver example

[Sathya Thammanur]

The Priority scheduler working with lwIP had fixes done and should be available with EDK8.2.1i release. 

Hope this helps

Sathya

On 10/18/06, address@hidden <address@hidden> wrote:

I am making some progress with the slow ping response times. I realised that
part of the problem was the use of SCHED_RR with a systmr_interval value of 10.
With the two threads used in responding to the ping request, these delays
accounted for most of the observed value. Setting the systmr_interval parameter
to 1 (the minimum?)reduced the ping times to 3 - 4 millisecs. I instrumented
the emac and lwip libraries and from the observed timings it seems that the
response time would be much better running under SCHED_PRIO.

At the present under SCHED_PRIO, I cannot get past lwip_init() in xemacif.c .
With gdb it looks as if the thread lwip_init_proper is never created so that
the variable lwp_init_proper_done is never set. It seems that something strange
is happening in the previous block where there semaphores, messageboxes etc are
setup, which probably means that I have missed setting up the xilkernel/lwip
parameters properly for use under SCHED_PRIO.

Any input again would be most welcome.

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
>





_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users