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 <[EMAIL PROTECTED]>: > On Wed, 2006-09-27 at 13:05 -0300, [EMAIL PROTECTED] 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
