Message: 2
Date: Wed, 24 Nov 2010 14:13:41 +0000
From: Kieran Mansley <address@hidden>
Subject: Re: [lwip-users] What's the max value of MEMP_NUM_NETCONN?
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
On 24 Nov 2010, at 08:45, runjin wrote:
What's the max value of MEMP_NUM_NETCONN?
Can I set it to 8192 ?
I doubt anyone has tried such a large value with lwIP. It might be
possible, but it wouldn't be efficient; lwIP just hasn't been written to
scale well with the number of sockets. There are places in the code for
example that do linear searches of lists of connections, and if the lists
grew that long it would take a long time.
Does lwip_select support more 8192 connections?
In what sense. The select() API generally only allows you to add a few
sockets to each select set as they are represented by bit masks. I can't
remember off hand how many lwIP supports but it's more like 32 rather than
8192. This is just the way the sockets API is defined, rather than a
restriction in lwIP (although again lwIP's implementation of select is
unlikely to be among the most efficient). For larger numbers of sockets
epoll() or similar would be a better choice, but lwIP does not currently
support that.
Kieran
------------------------------
Message: 3
Date: Wed, 24 Nov 2010 09:45:47 -0500
From: Chen <address@hidden>
Subject: [lwip-users] Re: lwip-users Digest, Vol 87, Issue 29
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Thank you, Simon!
1) I assume you made a typo when commenting TCP_WND?
"This must be at least * (2 * TCP_MSS) for things to work well"
seems apply to TCP_SND_QUEUELEN, and since #define
TCP_SND_QUEUELEN 6 * TCP_SND_BUF/TCP_MSS, it satisfies the
requirement
2) In my current configuration, which is derived from AVR32,
TCP_SND_BUF=30000
3) Since there are plenty data steaming to lwip, I am sure there are
more than 2 frames (1200 bytes each frame) enqueued, thus Nagle
shouldn't affect it
4) I am programming in socket level, I assume
lwip_setsockopt_internal is the API in this level to turn on/off
nagle, but I failed to find the online doc regarding its detail. Can
you give a pointer?
At this point, I still don't see why lwip should pause the
transmission after missing an ACK
I think that was a typo and Kieran meant TCP_SND_BUF (the send queue
limit in bytes). You might have to change TCP_SND_QUEUELEN (the send
queue limit in pbufs), too.
> Nagle's algorithm shouldn't affect my application since I am always
> sending 1200 bytes data all the time.
Based on how quickly the remote side ACKs the data, it might still
influence the send decision. The nagle algorithm sends if:
- no unacked data or
- more than one unsent segment or
- unsent segment has reached the maximum size
Since you have TCP_MSS set to 1500, it will *not* send a 1200-byte frame
directly, only if the last frame has been acknowledged or there are 2
frames enqueued. Therefore, the nagle algorithm might help.
Aside from that, TCP_MSS==1500 is not correct for ethernet. The MTU is
1500, so TCP_MSS is 1460 (MTU - sizeof(ip_hdr) - sizeof(tcp_hdr)). Also,
you seem to have ignored the comment on TCP_WND in opt.h:
"This must be at least * (2 * TCP_MSS) for things to work well"
I know it's sad we don't have a step-by-step guide for port creation or
memory configuration, but the already existing documentation (comments
in code, doc directory in the code ZIP, wiki) should have helped to
discover the limit of this setting...
Oh, and I think it's also questionable to turn off asserts when hunting
a problem. Unless you are really limited in processing speed and the
application doesn't run without assertions turned on, you should only
disable assertions once you know for sure your application runs stable.
Before that, you only risk masking problems. We included those
assertions for some reason, after all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.nongnu.org/archive/html/lwip-users/attachments/20101124/503657cb/attachment.html
------------------------------
Message: 4
Date: Wed, 24 Nov 2010 07:08:42 -0800
From: Tyrel Newton <address@hidden>
Subject: Fwd: [lwip-users] netconn api problem
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Resubmitting this question as I didn't get any feedback the first time
around.
I have an 10Mbit Ethernet application that strictly uses TCP via the
netconn API. All TCP writes are done with the NETCONN_COPY flag. I have
128MB of RAM in my system and all of the resource sizes set pretty high
in lwipopts.h. I monitor the resources and I have yet to see the max come
close to the avail.
A problem occurs when I do the following:
1) send a huge buffer via a single call to netconn_write with sizes well
over 64kB (usually in the 0.25~1 MB range)
2) immediately send a pretty small buffer (much less than the MSS for
Ethernet) via a single call to netconn_write
The problem is that the first byte (and only the first byte) of the
second netconn_write call seems to get dropped. This happens randomly and
not terribly frequently (maybe 10% of the time at worst). I can mitigate
the problem by inserting a few seconds of delay between the two calls to
netconn_write. The delay, I think, gives lwIP plenty of time to empty the
send buffer and process the numerous TCP ACKS that are required to send
the large buffer of data. The longer the delay, the less likely the first
byte of the second call gets dropped.
I'm connecting to lwIP from a Windows PC via a socket in python. I have a
hard time believing the PC is dropping the byte. I know I could verify
this with Wireshark, but since the problem is random and not too
frequent, it would take me forever to wade through the lengthy packet
history.
Anybody have any insight and/or guidance on where I might go in the code
or what settings I might tweak to fix and/or understand this issue?
Other lwipopts.h settings that might be relevant:
MEM_LIBC_MALLOC = 1
TCP_OVERSIZE = 1
LWIP_TCPIP_CORE_LOCKING = 1
LWIP_TCPIP_CORE_LOCKING_INPUT = 1
Thanks,
Tyrel
------------------------------
Message: 5
Date: Wed, 24 Nov 2010 10:17:32 -0500
From: "Bill Auerbach" <address@hidden>
Subject: RE: [lwip-users] netconn api problem
To: "'Mailing list for lwIP users'" <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
You could add a UDP broadcast after the big write and use that in
WireShark
to find the smaller packet that follows. Wouldn't you hate to go down
this
path for a long time to find out byte ends up being in the WireShark
capture? Sure, I agree, it's 99.9% sure not going to be there. But the
Wireshark capture might show other problems in and around that area. And
are there errors in the capture or is it clean?
Can you shrink iteratively the size of the first large send until the 2nd
send works? This might point to some size or boundary condition when the
problem appears.
Bill
-----Original Message-----
I'm connecting to lwIP from a Windows PC via a socket in python. I
have a hard time believing the PC is dropping the byte. I know I could
verify this with Wireshark, but since the problem is random and not too
frequent, it would take me forever to wade through the lengthy packet
history.
Anybody have any insight and/or guidance on where I might go in the
code or what settings I might tweak to fix and/or understand this issue?
Other lwipopts.h settings that might be relevant:
MEM_LIBC_MALLOC = 1
TCP_OVERSIZE = 1
LWIP_TCPIP_CORE_LOCKING = 1
LWIP_TCPIP_CORE_LOCKING_INPUT = 1
Thanks,
Tyrel
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
------------------------------
Message: 6
Date: Wed, 24 Nov 2010 07:45:42 -0800
From: Tyrel Newton <address@hidden>
Subject: Re: [lwip-users] netconn api problem
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
You could add a UDP broadcast after the big write and use that in
WireShark
to find the smaller packet that follows.
I like the UDP broadcast approach as it will give something unique to
trigger wireshark (and potentially my python scripts) against.
Wouldn't you hate to go down this
path for a long time to find out byte ends up being in the WireShark
capture? Sure, I agree, it's 99.9% sure not going to be there. But the
Wireshark capture might show other problems in and around that area. And
are there errors in the capture or is it clean?
Can you shrink iteratively the size of the first large send until the 2nd
send works? This might point to some size or boundary condition when the
problem appears.
Sure, but the problem is random enough that I'm not sure I could reproduce
anything useful in a controlled manner. At this point, I really think the
problem is a third party on our network that broadcasts something while
lwIP is sending the large chunk of data. And that something is somehow
screwing with lwIP's internals. I'm sure that turning on asserts and
debugging in lwIP would show what's wrong, but that would change the
dynamics of the situation by bringing throughput to a screeching halt.
I'll add the UDP broadcast thing and capture it my python scripts in
parallel, hopefully that will shed some light.
Thanks for the tip!
Tyrel
------------------------------
Message: 7
Date: Wed, 24 Nov 2010 11:31:56 -0500
From: Andrew Foster <address@hidden>
Subject: RE: [lwip-users] netconn api problem
To: lwip-users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="US-ASCII"
Tyrel,
You may also want to look into the STATS define in lwipopts.h. You could
invoke the stats_display function after you've detected the error. This
would allow you to observe the important stack structures without
drastically changing execution times.
If I've stated the obvious, I apologize.
Andrew
-----Original Message-----
From: Tyrel Newton [mailto:address@hidden
Sent: Wednesday, November 24, 2010 10:46
To: Mailing list for lwIP users
Subject: Re: [lwip-users] netconn api problem
You could add a UDP broadcast after the big write and use that in
WireShark
to find the smaller packet that follows.
I like the UDP broadcast approach as it will give something unique to
trigger wireshark (and potentially my python scripts) against.
Wouldn't you hate to go down this
path for a long time to find out byte ends up being in the WireShark
capture? Sure, I agree, it's 99.9% sure not going to be there. But
the
Wireshark capture might show other problems in and around that area.
And
are there errors in the capture or is it clean?
Can you shrink iteratively the size of the first large send until the
2nd
send works? This might point to some size or boundary condition when
the
problem appears.
Sure, but the problem is random enough that I'm not sure I could
reproduce anything useful in a controlled manner. At this point, I
really think the problem is a third party on our network that broadcasts
something while lwIP is sending the large chunk of data. And that
something is somehow screwing with lwIP's internals. I'm sure that
turning on asserts and debugging in lwIP would show what's wrong, but
that would change the dynamics of the situation by bringing throughput
to a screeching halt.
I'll add the UDP broadcast thing and capture it my python scripts in
parallel, hopefully that will shed some light.
Thanks for the tip!
Tyrel
_______________________________________________
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
End of lwip-users Digest, Vol 87, Issue 30
******************************************