Buffer size of send(), recv() for BEST performance
Alun Jones
<zwb...@yahoo.com> wrote:
>I'm talking about the buffer in my application. I suppose
>the system buffer of winsock is fixed, isn't it? It would
>be better if you can elaberate on both buffers :-) Thanks!
The buffer in Winsock can be sized using the setsockopt() option of SO_RCVBUF
and SO_SNDBUF (there's one buffer in each direction, unsurprisingly). Be
careful, though, as the stack is allowed to take the numbers provided in that
request, modify them, and then tell you it's successfully done your
setsockopt() call - always follow the setsockopt() call with a getsockopt()
call to see what _really_ happened.
Alun.
~~~~
[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place | http://www.wftpd.com or email al...@texis.com
Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.
arkadyf
SO_RCVBUF / SO_SNDBUF in setsockopt() .
You can set even to 0 that mean you said to the system to use your buffers
instead , sometimes you need it ( rear , multimedia in main )
but in almost in all cases . Look at good article in MSDN
"Common Performance Issues in Network Applications Part 1: Interactive
Applications"by Tom Fout and Art Shelest from MS
The default system buffer size changed from OS to OS and IIRC 8K for NT and
16K in W2K( the same XP ) . Usually , as MSFT stand , it's OK for almost
all cases.
As for you private buffer it's too depends upon app ( you can catch some
tips from above article ) but you
have to remember that TCP's MSS in ethernet is 1460 bytes so your data will
be divided on such blocks to be send.
Arkady
Wenrich <zwb...@yahoo.com> wrote in message
news:e8a801c26a72$e47da250$37ef2ecf@TKMSFTNGXA13...
> I'm talking about the buffer in my application. I suppose
> the system buffer of winsock is fixed, isn't it? It would
> be better if you can elaberate on both buffers :-) Thanks!
>
>
> >-----Original Message-----
> >Do you talk about your buffer ( in app ) or system buffer
> of winsock ?
> >Arkady
> >
> >"Wenrich" <zwb...@yahoo.com> wrote in message
> >news:faf501c26a1b$7ea68a20$39ef2ecf@TKMSFTNGXA08...
> >> Hi,
> >> To achive BEST performance of using Winsock APIs send(),
> >> recv() CAsyncSocket::Send(), and CAsyncSocket::Receive
> (),
> >> what would the size of buffer be? is there any limit on
> >> the size of buffer?
> >> Thanks a lot!
> >>
> >
> >
> >.
> >
Chris Becke
> I'm talking about the buffer in my application. I suppose
> the system buffer of winsock is fixed, isn't it? It would
> be better if you can elaberate on both buffers :-) Thanks!
Well - with TCP sockets with the nagle algorithm enabled your buffer size
selection is immaterial. You could call send repeatedly with a 1 byte buffer
and see no problems.
TCP sockets of course have send and recieve buffers that you can control the
size of using setsockopt SO_SNDBUF and SO_RCVBUF. There should be no real
performance implications tweaking the sizes of these, until the point that
is that they suddenly become too small.
As long as your application is reading data out of the socket - hell - one
byte at a time if you want - but as long as you read it out at least as fast
as its arriving the recieve buffers wont overflow, and unless your
application seriously tries to stream more data per second than the network
interface is capable of delivering, the send buffer wont overflow either.
Well - it does to a degree depend on your application - if youre trying to
send a lot of data very fast, your application will certainly exceed the
size of the send buffer. All thats important then is that the send buffer is
at least big enough such that - when the application recieves a FD_SEND to
indicate that some space has become available in it, that it is not
completely emptied (leaving the network interface with nothing to send)
before the app responds with another send to fill the buffer again. With any
reasonabley sized buffer (i.e. the default) and any reasonably responsive
app - this is not a problem.
Similar constraints hold for the recieve buffer. As long as the application
latency is not such that it cant read data faster than the network layer is
delivering it (I wish networks were that fast) - a reasonably/default sized
buffer will suffice.
The real options for tweaking network performance are the TCP window size
options - which are (I think) set globally for the entire socket stack.
Ed Astle
news:faf501c26a1b$7ea68a20$39ef2ecf@TKMSFTNGXA08...
> Hi,
> To achive BEST performance of using Winsock APIs send(),
> recv() CAsyncSocket::Send(), and CAsyncSocket::Receive(),
> what would the size of buffer be? is there any limit on
> the size of buffer?
> Thanks a lot!
>
Use google to search for "tcp buffer ethernet
group:microsoft.public.win32.programmer.networks author:astle" and this
brings up a couple of threads where I've commented on this subject before.
Regards,
Ed.
Alun Jones
>Well - with TCP sockets with the nagle algorithm enabled your buffer size
>selection is immaterial. You could call send repeatedly with a 1 byte buffer
>and see no problems.
That's not really true. The Nagle algorithm isn't going to smooth out
everything, and it's worth making an application tunable for different network
parameters. But the important thing to remember when writing a TCP
application - with or without Nagle in mind - is to send logically-connected
data together. If you've got a command and a terminator (end-of-line, for
instance), don't use two send() function calls.
>TCP sockets of course have send and recieve buffers that you can control the
>size of using setsockopt SO_SNDBUF and SO_RCVBUF. There should be no real
>performance implications tweaking the sizes of these, until the point that
>is that they suddenly become too small.
Your send buffer should be generally big enough that you can be filling it at
one end while it's being emptied at the other. This usually means at least
twice the receive window. The receive window, of course, should be at least
big enough to hold as much data as can be stuffed into the pipe (bandwidth
multiplied by latency), where latency includes how much time the receiver will
take in getting the data out of that window - in a well-written application,
this can be as close to zero as makes little difference.
>As long as your application is reading data out of the socket - hell - one
>byte at a time if you want - but as long as you read it out at least as fast
>as its arriving the recieve buffers wont overflow, and unless your
>application seriously tries to stream more data per second than the network
>interface is capable of delivering, the send buffer wont overflow either.
Pie in the sky. Your buffers will likely overflow at one point or another,
unless you're doing a very simple command/response protocol where commands and
responses are very short, and cannot be 'queued up'.
>The real options for tweaking network performance are the TCP window size
>options - which are (I think) set globally for the entire socket stack.
You can use SO_SENDBUF and SO_RECVBUF to set the window size if you call them
before listen() or connect(). Large window sizes can be useful if you have
either one or both of high bandwidth or high latency - remember, your window
size should be related to the value of bandwidth*latency - how many bytes can
physically be in transit at any one time.
arkadyf
NO , sure you can change system buffers too . Look at
SO_RCVBUF / SO_SNDBUF in setsockopt() .
You can set even to 0 that mean you said to the system to use your buffers
instead , sometimes you need it ( rear , multimedia in main )
but in almost in all cases . Look at good article in MSDN
"Common Performance Issues in Network Applications Part 1: Interactive
Applications"by
Tom Fout and Art Shelest from
MS
The default system buffer size changed from OS to OS and IIRC 8K for NT and
16K in W2K( the same XP ) . Usually , as MSFT stand , it's OK for almost
all cases.
As for you private buffer it's too depends upon app ( you can catch some
tips from above article ) but you
have to remember that TCP's MSS in ethernet is 1460 bytes so your data will
be divided on such blocks to be send.
Arkady
"Wenrich" <zwb...@yahoo.com> wrote in message
news:e8a801c26a72$e47da250$37ef2ecf@TKMSFTNGXA13...
> I'm talking about the buffer in my application. I suppose
> the system buffer of winsock is fixed, isn't it? It would
> be better if you can elaberate on both buffers :-) Thanks!
>
>
> >-----Original Message-----
> >Do you talk about your buffer ( in app ) or system buffer
> of winsock ?
> >Arkady
> >
> >"Wenrich" <zwb...@yahoo.com> wrote in message
> >news:faf501c26a1b$7ea68a20$39ef2ecf@TKMSFTNGXA08...
> >> Hi,
> >> To achive BEST performance of using Winsock APIs send(),
> >> recv() CAsyncSocket::Send(), and CAsyncSocket::Receive
> (),
> >> what would the size of buffer be? is there any limit on
> >> the size of buffer?
> >> Thanks a lot!
> >>
> >
> >
> >.
> >
arkadyf
(HKLM\SYSTEM\CurrentControlSet\Services\Tcp\Parameters\Interfaces\{Adaptor
GUID}
is parameter setting window size
generally ( in registry ) .Its default value is 8760 for ethernet
( 6 times MSS for ethernet 1460 * 6 = 8760 ) in NT .
With SO_SNDBUF you can change it for current socket in registry for all.
In W2K it's value twice of NT ( 17520 = 1460 *12 )
Look at
"Windows 2000 Does Not Use Configured TCPWindowSize Registry Parameter When
Accepting a Connection" Q263088 for MSDN's KB.
Arkady
"Chris Becke" <chr...@microgaming.com> wrote in message
news:#Wpwt63aCHA.2588@tkmsftngp12...
arkadyf
"INFO: Design Issues - Sending Small Data Segments Over TCP w/Winsock"
Q214397 of MSDN KB
Arkady
"Alun Jones" <al...@texis.com> wrote in message
news:avkn9.38$2i3.7...@newssvr30.news.prodigy.com...
arkadyf
google take one /two threads per day. Something wrong happen to google's ng
archiving . I wrote to them but alas ...( the robot answered quickly enough,
but nothing after it :( )
Their e-mail : groups-...@google.com.
Arkady
"Ed Astle" <ed.REMOVE_...@tfeurope.com> wrote in message
news:3d9d6ec4$1...@primark.com...