Re: [lwip-users] losing input packets and repeated acks

[Jonathan Larmour]

Carl D. Blake wrote:
> I've attached my lwipopts.h file and a tcpdump trace.

I just noticed a few things in your config too...

> /* #define TCP_TMR_INTERVAL     250 */
> #define TCP_TMR_INTERVAL        10

That is very very small. You will probably be too busy processing the TCP 
timer to do any real work. The default should be adequate.

> #define PBUF_POLL_SIZE          30

This should be PBUF_POOL_SIZE, not POLL. You will therefore have 16 
buffers by default instead.

> #define PBUF_POOL_BUFSIZE       1536

Are you sure you mean 1536 and not 1500?

> #define PBUF_LINK_HLEN          16

Are you sure you mean 16 and not 14?

> #define TCP_MSS                 1476

Again I would have expected this to be 1460 (just like your peer in the 
trace below). Fortunately for you, your peer won't go above 1460, so you 
won't see any problem, but this value still seems wrong, unless there's 
something unconventional about your setup.

> #define TCP_WND                 (16 * 1024)

16K, but you only have 16 pbufs, so it will be easy to run out of pbufs. 
You will use 1 pbuf even if you only receive a tiny packet, and that 
includes acks. It does dependent somewhat on your data pattern, but it is 
usually more efficient to have a larger number of smaller pbufs. It's 
usually better to have 3 500-byte pbufs than 1 1500-byte pbuf. Remember 
that pbufs can be chained.

> ------------------------------------------------------------------------
>
> 13:53:58.646727 boromir.tucson.boeckeler.com.10001 > 10.0.1.222.4098: P 
> 904882:904904(22) ack 1 win 5840 (DF)
> 13:53:58.649988 boromir.tucson.boeckeler.com.10001 > 10.0.1.222.4098: . 
> 904904:906364(1460) ack 1 win 5840 (DF)
> 13:53:58.651482 boromir.tucson.boeckeler.com.10001 > 10.0.1.222.4098: . 
> 906364:907824(1460) ack 1 win 5840 (DF)
> 13:53:58.654904 10.0.1.222.4098 > boromir.tucson.boeckeler.com.10001: . ack 
> 906364 win 11094 (DF)
> 13:53:58.654912 boromir.tucson.boeckeler.com.10001 > 10.0.1.222.4098: P 
> 907824:909284(1460) ack 1 win 5840 (DF)
> 13:53:58.654915 boromir.tucson.boeckeler.com.10001 > 10.0.1.222.4098: P 
> 909284:909926(642) ack 1 win 5840 (DF)
> 13:53:58.655868 boromir.tucson.boeckeler.com.10001 > 10.0.1.222.4098: . 
> 909926:911386(1460) ack 1 win 5840 (DF)
> 13:53:58.661166 10.0.1.222.4098 > boromir.tucson.boeckeler.com.10001: . ack 
> 906364 win 12576 (DF)

Nevermind the huge delay later, you are getting problems right here. You 
will probably find you are out of pbufs. You are advertising a larger 
window than you have memory to accept, so the remote size is still 
flinging data at you. If you allow out of sequence packets, this may also 
explain the large delays, as they will use up pbufs waiting for any 
missing data, but there would be no pbufs left to allow the missing data 
to come in!

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
Company legal info, address and number:   http://www.ecoscentric.com/legal
------["The best things in life aren't things."]------      Opinions==mine