Now I'm more confused. I found a post by "bill", which appears to be regarding v1.3 who said:
"What is your TCP_SND_QUEUELEN? If you tie up all of your pbufs to send queued packets, you won't have any pbufs left to support receiving packets." Is there any truth to this statement (except for the case you mention about out of order segments)? I wish there was a thorough description of each parameter somewhere. opt.h is fairly good, but there's a few I'm lost on. Here's the ones I'm unsure about, lets try that: TCP_SND_BUF - Buffer for outgoing segments. Does this include ACKs? How is it divided up between segments? Why doesn't the RAM usage change when this is changed? Where does the memory for this get allocated from? MEM_SIZE - Memory strictly for Tx data when it is copied. I see that RAM usage does change when this is modified, so this makes sense. MEMP_NUM_PBUF - The number of pbuf structs for Tx segments that contain data NOT copied (REF or ROM). Does this have anything to do with ACKs? MEMP_NUM_TCP_SEG - Total number of Tx segments in queue, including RAM, ROM, or REF types. Does this have anything to do with ACKs? TCP_SND_QUEUELEN - Number of pbufs for Tx. Confused by this one. What is the size of the pbufs? Where does the memory for these get allocated from? Is this for all three types, RAM, ROM, REF? Does this include ACKs? I ask about ACKs a lot because my application doesn't transmit much more than ACKs since it's streaming data. I still get too many dropped packets, however I see virtually none with default lwIP settings. The defaults are less than ideal however, especially with the very low MSS. --- On Mon, 8/3/09, [email protected] <[email protected]> wrote: From: [email protected] <[email protected]> Subject: Re: [lwip-users] Relationship between lwIP options To: "Mailing list for lwIP users" <[email protected]> Date: Monday, August 3, 2009, 1:37 PM JM schrieb: > I'm trying to understand all these options in opt.h/lwipopt.h so I can assign > them intelligently instead of guessing and wondering why communication > fails. So, this is what I think is correct; please correct me if I'm wrong: > > In the case of all PBUFs being the same size as defined by PBUF_POOL_BUFSIZE: > > -There is no point in making MEMP_NUM_TCP_SEG > PBUF_POOL_SIZE since each > segment must use one PBUF at minimum, and actually can cause dropped packets > since there will be no space for incoming packets despite MEMP_NUM_TCP_SEG > not hitting its limit. > These two (tcp segments and the pbuf pool) are not really related to each other: segments are used for outgoing packets only (in conjunction with RAM- or REF-pbufs), while the pbuf pool is only used for incoming packets. The only exception for that rule is that segments are also used for out-of-order segments on the RX side, but that's another issue... > > -(TCP_SND_BUF / PBUF_POOL_BUFSIZE) is the effective limit on the number of > outgoing segments in the queue, so TCP_SND_QUEUELEN might as well be set > equal to this limit, at least in the case of very small outgoing packets that > fit into one PBUF. > Totally not: as I already wrote above, the pbuf pool is used for RX packets only! For each call to tcp_write(), one or more PBUF_RAM pbufs are enqueued (if copying data; if not copying, PBUF_REF is allocated) in a segment. Multilpe pbufs are then enqueued for one segment until that segment reaches the maximum segment size, at which point a new segment is allocated and pbufs are in turn enqueued to it. Thus TCP_SND_BUF (number of outgoing unacked bytes) can not berelated to the number of pbufs used for these bytes. This allocation strategy is not the optimum we can get, which is why we started a one-pbuf-per-segment approach, which is, however, not yet included in CVS or v1.3.1. Simon > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
