Noam weissman: I have a problem that I have seen lots or users straggling with, but without any real solution. I am trying to send data in a loop. I have triad closing NAGLE as follows: // this shoul
Dear Kieran, so far, I was not able to set TF_NODELAY. My question was, where would I have to specify this option? Can you help me here? Here a short snap of lwipopts.h: /* Controls if TCP should que
That's the TCP delayed ACK algorithm. I suspect what you're seeing is this interacting badly with the Nagle algorithm that delays sending data until there is a full segment to send. TF_NODELAY disabl
Thank you so much for the reply! Yet, I suppose I am still somewhat convinced that I have setup something incorrectly. The inefficiency of such an algorithm (Nagle's) seems mind-boggling. Take the fo
That's perfectly correct and not odd at all: the nagle algorithm tries to improve the overall network load by not sending too many small packets. What you need is the opposite: low latency. It's per
Bill Auerbach wrote: I see - tcp_output isn't a "send now" - I thought it meant that (if not, why do a tcp_write *and* a tcp_output?). So with tcp_output, Nagle delays are not circumvented. The contr
I see - tcp_output isn't a "send now" - I thought it meant that (if not, why do a tcp_write *and* a tcp_output?). So with tcp_output, Nagle delays are not circumvented. The contrib example doesn't d
Bill, As we suspected based on this information, setting the TF_NODELAY flag in the accept callback did not make a difference. Apparently the problem is somewhere else in the stack but not sure where
Ok. Than as Simon pointed out – the tcp_output avoids Nagle. I followed the contrib/apps httpd example and without tcp_output calls I needed TF_NODELAY. Which is right? I would hope that an lwI
That's intrinsic to tcp_write. tcp_write only enqueues. It needs tcp_output to actually send anything (possibly called via tcp_output_nagle as you notice below...) Precisely to allow a number of sepa
I have investigated further into this matter and this is what I found: After enabling the Nagle algorithm again the server responds with these 5 blocks and some extra characters when telnet connects.
I too have seen problems with Nagle's algorithm, and it's not limited to lwIP - see: http://www.acm.org/sigcomm/ccr/archive/2001/jan01/ccr-200101-mogul.pdf Also, there are different definitions of th
Hello Again, thank you very much. I probably am just really bad at using these sources but I find it hard to find all the info so your help is really great. So I have now a different setup, still jus
Thanks for the reply! Actually, the end goal is to integrate the solution into rfcomm. For now, the "physical layer" is being simulated by a single local host tcp connection(under Android OS). The lo
Good day! I have lwip library test application (tcp_echo) on my machine and a netcat server on virtual box. ILWP tcp_echo was changed to be a client. now it looks like: static void tcpecho_thread(voi
Yeah, the problem is not lwIP! I'm using an M3 at 120MHz, and have megabit performance. So optimizing how you fill buffers is a waste of time. As Krzysztof pointed out, you need to find the real caus
It's probably the long standing issue (not specific to lwIP) of the problems with one end using Nagle's algorithm and the other end uses delayed ACKs. You should disable one or the other and try that
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 t
thanks, but two things a) sometines i only have to send 10 bytes is that a big problem? b) the Nagle algorithm, i don´t known by default its value. I should use this function setsockopt to desac