strange TCP stack behiviour with write()es in pieces
Quoted 10 lines · David Schwartz
Quoted 7 lines · Michal Moskal
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 tomalloc()buffer, second version is still by orders of magnitude faster.
Quoted 3 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Signature · 4 lines
: 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 memberQuoted 7 lines · Michal Moskal
Quoted 4 lines
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.
However, with Nagle disabled, there is no bound to how poor network
efficiency can be. If you do a single byte write every tenth of a second, you will send out a packet for each single byte.
You can only disable Nagle if you can assume that the application is smart
enough to do the coalescing. After all, someone has to. Since we're talking about an app that can't coalesce, you cannot disable Nagle. (Unless you consider it acceptable to send one byte of data in each packet.)
Again, an application *must* *not* disable Nagle unless it (the app) takes
responsibility for ensuring that data is sent in large enough chunks to ensure network efficiency. So you can disable nagle if you want to, but not until *AFTER* you make sure your application coalesces writes.
DS