Re: [lwip-users] Sending too slow.

[Mateusz Plocinski]

Hi,
I would like to thank people who were interested in my problem :). I've learned 
much, thanks.
In my situation the problem was well... stupid because I've set:
#define TCP_MSS                 1460
#define TCP_SND_BUF             1460
so it couldnt send more than one packet without getting ACK, and after changing 
TCP_SND_BUF, it works much faster. I also see that WinXP, when receives two 
full packets, sends ACK much faster than 200ms, strange mechanism, I think.

Now I have much more problems, for example when I overload lwip queuing (from 
lwip+freertos side) 64KB packets very fast, it hangs my whole OS after few 
seconds (and it shouldnt be possible), but its probably the problem of my port. 
I'll try to turn on these debug functions, maybe they could tell me more.

> > The way that the packets are being sent (1460 followed by 40) is because
> > of an issue in tcp_enqueue that I noticed last November, unfortunately I
> > haven't had time to submit what would be a quite complicated patch..
> > The problem is benign apart from the fact it makes the link inefficient.
> > Tcp_enqueue first splits the received data into segments all of mss size
> > apart from the last, it then checks the last segment on the unsent queue
> > and attempts to join the segments if the last is also less then mss.
> > This works fine if you are doing small writes, however if you do writes
> > (worst case mss+1 bytes) you end up with <mss> <1 byte> <mss> <1 byte>
> > rather than <mss> <mss> <2 bytes>.
> > Basically, the code needs modifying to check the space of the last
> > unsent before it splits the new data into mss sized units, but this
> > would need quite a large patch...

For me, it would be the best if tcp_enqueue wouldnt try to join anything, 
because I'm queuing big frames. Is it done that way to increase performance? 
I'll try to turn it off later if it will be possible.

Mateusz