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

[Chen]

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.