[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] TCP performance in receiving
From: |
Craig Graham |
Subject: |
Re: [lwip-users] TCP performance in receiving |
Date: |
Tue, 12 Oct 2004 12:31:06 +0100 |
User-agent: |
KMail/1.6 |
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
- Re: [lwip-users] TCP performance in receiving, (continued)
- Re: [lwip-users] TCP performance in receiving, Wei Bo-Er \(Jason\), 2004/10/10
- Re: [lwip-users] TCP performance in receiving, Craig Graham, 2004/10/11
- Re: [lwip-users] TCP performance in receiving, K.J. Mansley, 2004/10/11
- Re: [lwip-users] TCP performance in receiving, Atte Kojo, 2004/10/11
- Re: [lwip-users] TCP performance in receiving, K.J. Mansley, 2004/10/11
- Re: [lwip-users] TCP performance in receiving, Atte Kojo, 2004/10/11
- Re: [lwip-users] TCP performance in receiving, K.J. Mansley, 2004/10/11
- Re: [lwip-users] TCP performance in receiving, Wei Bo-Er \(Jason\), 2004/10/12
- Re: [lwip-users] TCP performance in receiving, Craig Graham, 2004/10/12
- Re: [lwip-users] TCP performance in receiving, Atte Kojo, 2004/10/12
- Re: [lwip-users] TCP performance in receiving,
Craig Graham <=
- Re: [lwip-users] TCP performance in receiving, K.J. Mansley, 2004/10/16
- Re: [lwip-users] TCP performance in receiving, Craig Graham, 2004/10/11
Re: [lwip-users] TCP performance in receiving, Sigurd Vindenes, 2004/10/27