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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:21 EST