Re: [lwip-users] TCP performance in receiving

[Craig Graham]

Ok, additional figures here 
Stock 1.0.0 (with cvs mods)                   74s        100% (baseline)
tcp_recved() mod (Craig version)              29s        255%
tcp_recved() mod (Atte, threshold==TCP_WND)   37s        200%
tcp_recved() mod (Atte, threshold==TCP_WND/2) 31s        238%
tcp_recved() mod (Atte, threshold==TCP_MSS)   24s        300%
tcp_recved() mod (Atte, threshold==0)         29s        255%

This was for TCP_WND=8096, TCP_MSS=1024.

Quite an interesting exercise (and I think I'll leave it at that point unless 
someone comes up with a better fix). The improvement in TCP performance 
(like, 300% on my local network) is pretty handy though :)



On Tuesday 12 October 2004 10:48, Atte Kojo wrote:
> Craig Graham wrote:
> > Stock 1.0.0 (with cvs mods)      74s        100% (baseline)
> > tcp_recved() mod (Craig version) 29s        255%
> > tcp_recved() mod (Atte version)  37s        200%
> >
> > ie. It's performance isn't as good as the patch I posted yesterday. Don't
> > suppose anyone else fancies running a few TCP performance tests to
> > confirm this?
>
> These ressults are expected based on the ways our mods work. Your
> modification sends out a forced ack as soon as the window size is
> updated whereas my modification waits until the window is empty until
> sending out a forced ack. Thus there is a slightly longer delay before
> the forced ack is sent (depending on how slow the receiving application
> is in processing the data) in my version.
>
> I decided to wait until the window is empty before sending the forced
> ack to avoid advertising small window sizes. This of course imposes a
> delay because the receiving application then has to wait for new data to
> arrive after it has drained the stack.
>
> Your version is faster because it feeds the application constantly with
> data, because the stack never gets empty (at least not when the
> modification itself is considered). On the other hand, there is a
> possibility of multiple duplicate acks if the sending stack refuses to
> send data to a small window.
>
> One possibility is to make the threshold for sending forced acks lower
> than TCP_WND but high enough so as to not advertise very small windows
> (for example 1/2 * TCP_WND or 3/4 * TCP_WND). This should have the
> benefits of both approaches. Would you like to test it?
>
>       - Atte