Re: [lwip-users] Fw: (no subject)

[Anirudha Sarangi]

Hi,

The other ting to add is I undefined LWIP_TIMERS as I could not understand the use of timers.c

 

regards

Anirudha

From: Anirudha Sarangi <address@hidden>
To: Mailing list for lwIP users <address@hidden>
Sent: Wednesday, 28 September 2011 1:13 PM
Subject: Re: [lwip-users] Fw: (no subject)

Hi Kieren,

I just upgraded from lwip130 to lwip140. When I run iperf, I see a drop in performance numbers on the Tx side. I am running lwip on microblaze (xilinx).

Earlier with lwip130, my rxperf number was 129 Mbps and Txperf number was 102 Mbps.

After upgrading to lwip140, my rxperf number increased to 140 Mbps (which is great), but Txperf number came down to 67 Mbps. A drastic fall.

 

I actually tried lwip132 as well. Here I see no drop in the numbers. The drop comes only for 140.

 

Is there any configuration I missed ? I see that for lwip140 a number of new parameters are added and also almost all source files have changed. With my limited TCP/IP and nteworking knowledge it is almost impossible for me to know the reason. Could you help me a bit?

 

For lwip 130, on top of opt.h, I had a configuration file which changed some of the values defined in opt.h. My configuration looked like the following. I am using the same for lwip140 port as well. Do you advise any new configurations?

 

regards

Anirudha

 

 

#define SYS_LIGHTWEIGHT_PROT 1

#define NO_SYS 1
#define LWIP_SOCKET 0
#define LWIP_COMPAT_SOCKETS 0
#define LWIP_NETCONN 0

#define MEM_ALIGNMENT 64
#define MEM_SIZE 131072
#define MEMP_NUM_PBUF 16
#define MEMP_NUM_UDP_PCB 4
#define MEMP_NUM_TCP_PCB 32
#define MEMP_NUM_TCP_PCB_LISTEN 8
#define MEMP_NUM_TCP_SEG 256
#define LWIP_USE_HEAP_FROM_INTERRUPT 1

#define MEMP_NUM_SYS_TIMEOUT 8
#define PBUF_POOL_SIZE 256
#define PBUF_POOL_BUFSIZE 1700
#define PBUF_LINK_HLEN 16

#define ARP_TABLE_SIZE 10
#define ARP_QUEUEING 1

#define ICMP_TTL 255

#define IP_OPTIONS 0
#define IP_FORWARD 0
#define IP_REASSEMBLY 1
#define IP_FRAG 1
#define IP_REASS_BUFSIZE 5760
#define IP_FRAG_MAX_MTU 1500
#define IP_DEFAULT_TTL 255
#define LWIP_CHKSUM_ALGORITHM 3

#define LWIP_UDP 1
#define UDP_TTL 255

#define LWIP_TCP 1
#define TCP_SND_QUEUELEN   16 * TCP_SND_BUF/TCP_MSS
#define TCP_MSS 1460
#define TCP_SND_BUF 8192
#define TCP_WND 8192
#define TCP_TTL 255
#define TCP_MAXRTX 12
#define TCP_SYNMAXRTX 4
#define TCP_QUEUE_OOSEQ 1
#define CHECKSUM_GEN_TCP 0
#define CHECKSUM_GEN_UDP 0
#define CHECKSUM_GEN_IP 0
#define CHECKSUM_CHECK_TCP 0
#define CHECKSUM_CHECK_UDP 0
#define CHECKSUM_CHECK_IP 0

#define LWIP_DHCP 0

From: Kieran Mansley <address@hidden>
To: Mailing list for lwIP users <address@hidden>
Sent: Friday, 15 July 2011 6:09 PM
Subject: Re: [lwip-users] Fw: (no subject)

On Fri, 2011-07-15 at 14:28 +0800, Anirudha Sarangi wrote:


> What my conclusion is, since noone has ever reported such an issue
> with lwip, it could not be a lwip issue. Since my application does not
> do great things, it cant be application issue as well. So my suspect
> is, the way I configure lwip and the way I have ported lwip.

I agree with your conclusion.

> Could you take a look at the log and let me know if you could make out
> anything.

You haven't said which end is lwIP, and I don't remember the exact
details of your problem, but from what I can see in the packet capture:

Frame 489: 192.168.11.10 sends TCP seq 98398828->98400228
Frame 490: this packet is ACKed by the other end (192.168.11.1)
Frame 491: .10 sends the same packet again.  This is odd, and I think
the root of the problem.
Frame 492: .1 says "I've already got that"
Frame 493: .10 sends TCP seq 98401628.  The next packet expected would
be 98400228 (i.e. there is a gap of 1400 bytes or ~1 packet)

.1 then continues to send ACKs for the sequence it has received in
order, to tell the .10 to retransmit the missing sequence.  This is how
TCP deals with loss and retransmission.  .10 carries on with new packets
for a while (also normal) but then does what looks like a retransmission
in frame 499, but it is a retransmission of frame 493, not the missing
packet.  This suggests that lwIP doesn't have the missing packet
anymore.

I think the duplicate packet in frame 491 should have had the contents
of the missing packet.  You've sent the correct number of packets, but
one of them was sent twice, and one of them not at all.  This could be
that the TCP send queue got corrupted due to a porting error, or that
the driver did something wrong, or something else that I haven't thought
of.  The fact that lwIP is unable to retransmit the missing packet (and
instead sends the one after it) does point to the lwIP packet queues
being corrupted, and this is usually because of a concurrency problem.

I'm afraid that I won't be able to give you the solution to your problem
as it is likely to be difficult to get to the bottom of, and without
your code and hardware I wouldn't be able to debug it (not to mention
that I don't have the spare time!), so you're going to have to either do
this yourself, or get someone with some experience in this area to help
you.  Whoever wrote the port of lwIP that you're trying to debug would
be a good first step.

Finally, I probably mentioned this before, but you're trying to debug a
problem with a port of 1.3.2, which is now an old version of lwIP.  It
will become increasingly unsupported in the future, so if you are able I
would recommend upgrading to 1.4.0.

I hope that helps.

Kieran


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