lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Re: lwip-users Digest, Vol 87, Issue 27


From: address@hidden
Subject: Re: [lwip-users] Re: lwip-users Digest, Vol 87, Issue 27
Date: Tue, 23 Nov 2010 19:42:57 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

Chen wrote:
Kieran, thanks for the reply

I can't find TCP_SND_WND in lwipopts.h (see attachment)

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.

Simon

reply via email to

[Prev in Thread] Current Thread [Next in Thread]