Re: How relevant is "Automatic TCP Window Tuning" in Networking Applications ?

Just a little addition Mike!
From W2K all windows OK have default 16K size, in NT that was 8K once
Arkady
P.S. For OP : maybe need be checked ) better solution can be zero-buffering
( set send buffer to 0 ) and use user-mode buffer ( as big as you want ) for
transittion.

"Michael K. O'Neill" <MikeAThon2000@xxxxxxxxxxxxxxxxxx> wrote in message
news:%23mkV%23RvRHHA.1600@xxxxxxxxxxxxxxxxxxxxxxx

"sharekhan" <saneax@xxxxxxxxx> wrote in message
news:1170424909.385576.96550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hello Everyone.
My earnest apologies, since I already posted this message in
comp.lang.c++. However, later I realized, this might be a better
forum, since I am coding on windows platform.

I have come across this article (http://dast.nlanr.net/Projects/
Autobuf_v1.0/autotcp.html) called "Automatic TCP window tuning". After
my first newbie file transfer I wrote and found that it was just
extremely slow over net, compared to http or ftp. I have been thinking
of reasons. After reading the article I modified the server and
clients.. in the following way..

server...
/*setting socket Opttions to windows size to 780K.. 780 *
1024*/
int window_size = 2000 * 1024;
mySocket = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(mySocket, SOL_SOCKET, SO_SNDBUF,
(char *) &window_size, sizeof(window_size));
setsockopt(mySocket, SOL_SOCKET, SO_RCVBUF,
(char *) &window_size, sizeof(window_size));

on client...

/*set Socket Option.. 1000 * 1024*/
int window_size = 780 * 1024;
s = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(s, SOL_SOCKET, SO_SNDBUF,
(char *) &window_size, sizeof(window_size));
setsockopt(s, SOL_SOCKET, SO_RCVBUF,
(char *) &window_size, sizeof(window_size));
/*End Of set Socket Option*/

with this I got a better transfer rate.. I mean 10 times faster. :)
its even better in LAN. I got 1 GB transfered in 200 secs. faster than
it took to create the file.


There's no reason to set the buffers as large as you have done. The
typical
estimate for size is given by this equation:

size = Round-Trip-Time * Bandwidth

where RTT is the round trip time between TCP's sending of data and receipt
of its ACK, and Bandwidth is the bandwidth of the network.

For a local network of 100 MBits/sec, a really awful RTT is around 1
millisecond. Using the above equation, you get a buffer size of 100000000
mbps divided by 8 bits per byte times .001 seconds = 12500 bytes.

For Internet connectivity over (say) ADSL, the bandwidth is around 1.5
mbits/sec and the RTT is around 75 milliseconds. So the buffer should be
around 1500000/8*.075 = 14062 bytes.

In normal Windows installations, the default size of the buffers is 8K.
So
in general, yes, it makes sense to increase them. But increase them to
16K,
not to 2000K and 1000K like you have done. This is simply wasteful of
resources, which might not show up if you are creating only a single
socket,
but which will quickly manifest itself as more and more sockets are
created.

Note that if it takes 200 seconds to transfer your 1G file over an
Ethernet
LAN running at 100 MBits/sec, then you are still not using the full
bandwidth of the network. The file should have gone in around 80 seconds
at
full-hilt. There is probably some other issue with your code.

You might also ask this over at alt.winsock.programming



Now I have a question, do Apache (HTTP server) and FTP servers employ
such a TCP window tunning. Is it hard coded ( I mean is there a
optimum value known ?) for all types of networks ?
since even when I download a file through HTTP its nearly the same
speed, as I achieved by increasing the TCP window.

cheers.


I don't know what Apache or FTP servers do. Apache is open-source, so you
can check for yourself.

Mike




.

Relevant Pages

  • Re: How relevant is "Automatic TCP Window Tuning" in Networking Applications ?
    ... and Bandwidth is the bandwidth of the network. ... For a local network of 100 MBits/sec, a really awful RTT is around 1 ... In normal Windows installations, the default size of the buffers is 8K. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Parasitic Computing
    ... view the technology as much of a threat, ... Network bandwidth is like a river flowing into the ... If you go up stream you find less and less bandwidth per node. ... across thousands of much slower upstream nodes (victims). ...
    (comp.os.linux.security)
  • Re: Routing and bandwidth problem
    ... Subject: Routing and bandwidth problem ... > so that each client is properly isolated into their own network and cannot ... It seems to me that multiple Ethernet cards ... > Connex automatically scans all messages for viruses using RAV AntiVirus. ...
    (RedHat)
  • Re: IRC-based Olympic Coverage
    ... >> when it comes to network and computer security. ... anything to do with IRC. ... Looking at what experience have told me, regular web browsing at work ... E-Mail will probably top the list (total bandwidth over 24 hours, ...
    (comp.security.firewalls)
  • Re: Band Width
    ... My wife came home with a complete schematic of the Network setup where she ... Is this truly a "bandwidth" concern? ... If she is listening to radio at 32kbps and their LAN is a 100mbps network ... internet connection, then on paper that still leaves 90% of your LAN ...
    (microsoft.public.win2000.advanced_server)