Re: [lwip-users] TCP performance in receiving

[Atte Kojo]

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

--
I WILL NOT SNAP BRAS
I WILL NOT SNAP BRAS
I WILL NOT SNAP BRAS
I WILL NOT SNAP BRAS

        Bart Simpson on chalkboard in episode 8F22