Hi, Can you disable the nagle algorithm to be sure? (in this case, you should also have 3 frames, but, if the problem is in segment concatenation, you should got good datas) About your sample, since
It's probably possible, but it would be a non-general modification to the stack that you'd need to do yourself, rather than just a configuration option. Network ACKs can be sent for many reasons, and
Hi, I'm in the process of porting an existing application to a new platform that uses lwIP. This application operates in real time using a series of commands from a server. The application layer of t
No it stops completely. The receive window is open. However I am not sure about the congestion window (might be messed up). Or it could be a bug in my application L Regards Ram From: address@hidden [
Does it stall for a few seconds and then resume? I was seeing this on my system, and the stall was occurring on the host computer. The reason was that the TCP window on my lwIP board was small enough
Hi Kieran, I looked into the use of TCP_NODELAY. If this option is set, the result is to add TF_NODELAY to tcp->flags. In api_msg.c in do_write() this flag is used as shown in the code fragment below
Thomas, Thanks for your response. I think most of my original questions have been traced to a corrupt MAC address in the segment sent using lwip (visible in the log file I sent you). This causes the
From: Paul Butler [mailto:address@hidden Sent: Tuesday, April 03, 2007 12:04 PM To: Taranowski, Thomas (SWCOE) Subject: Re: [lwip-users] lwip and/or general tcp problems Thomas, Thanks for allowing m
All, It appears many of my earlier problems were due to ADI using version 1.1.0 for the basis of their port (not 0.6.3 as I previously indicated), which had a problem with the Nagle algorithm. They a
Ideally TCP_SND_BUF should be many times greater than TCP_MSS. This is due to the queuelen being stored in an 8 bit value. Someone posted a simple modification earlier in the week should you wish to
Hi group, I look for informations about tunning TCP in lwipopts.h. I have to send large TCP packets, with minimum delay, so, I try to find in newsletter archives some informations. But I don't know e
A better solution would be the one mentioned in this post to the mailing list: http://lists.gnu.org/archive/html/lwip-users/2006-09/msg00060.html Hopefully this change (although probably not the enqu
Hi, I'm not an tcpip expert too, but I've worked with lwip for past few weeks. I had exactly the same problem like yours, also using SAM7X256 processor. I solved the problem changing following thing
Yes. Sounds like you're using the raw API already, so that is good as far as performance goes. Depending on your exact traffic pattern, if you're using WinSock on the other end you may need to disabl
If you're using the raw API, then there is no Nagle algorithm - it's implemented in api_msg.c which is one of the higher layered APIs. Did you try looking at the loop in tcp_output() to see why it's
I have found out the problem..... linux socket program will use NAGLE/delayed ACK...algorithm. If I use "tcp_write();tcp_output();" to send a packet(1024 bytes ) to the linux socket prgram!! it will
I found the solution...the key is the nagle-algorithm. I only had to set the TF_NODELAY to 1. Thanks, Max Von: Kolpak, Maximilian (ext) Gesendet: Mittwoch, 12. Juli 2006 15:44 An: 'address@hidden' Be
The issue of non-32bit aligned access has come up a lot recently. Having the Ethernet header on a 16 bit boundary is a standard way of ensuring the IP and TCP headers are 32 bit aligned (but does mea
Hi all, I have been porting the lwip onto TI C6203 dsp. The porting required a change to pbuf_alloc() & I believe I have encountered two bugs in the tcp->tmr & tcp->cwnd: 1. Changes needed in pbuf_al
I think it should just be documented so people can optimize for either latency or throughput. It can even change inside the same code. For example a telnet server should be low latency, while ftp tra