Re: strange TCP stack behiviour with write()es in pieces

[Michal Moskal <malekith@pld.org.pl>]

On Wed, Jan 02, 2002 at 01:49:56PM -0800, David Schwartz wrote:
> 
> On Wed, 2 Jan 2002 17:28:06 +0100, Michal Moskal wrote:
> >I, personally, would expect the second version to be at most two times
> >slower (as there might be need to send two IP packets instead of one).
> >Also note, that as it is obvious that version with copying to buffer on the
> >stack should be faster, it is not so obvious if there is need to malloc()
> >buffer before sending (for example if there is no upper limit on len).
> >However even if we need to malloc() buffer, second version is still by
> >orders of magnitude faster.
> 
> 	If you can design an algorithm that makes that only two times slower, then 
> the world will be excited and interested and perhaps that algorithm will 
> replace TCP. But until that time, we're stuck with what we have.

With negle disabled it works 17/15 times slower, which is much less then
two. Similary with UNIX domain sockets.

> >I found it during work with client/server program that worked horribly slow
> >just becouse of this. (of course I fixed it, but that's not the point).
> 
> 	THAT IS THE POINT. The problem wasn't in the kernel, it was in the program, 
> and you fixed it. If you do smart buffering, TCP can behave efficiently. If 
> you don't, it has to guess when to send packets, and it can't possibly 
> predict the future and behave in the way you think is optimum.

Ok, *now* I know that ;)

Thank you all for pointers.

-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:    Linux: We are dot in .ORG.    |                : {b,e>+}++ !tv h
: CurProj: ftp://ftp.pld.org.pl/people/malekith/ksi : PLD Team member