Si quieres recibir más cantidad de bytes y a la vez enviar menos ACK, que permita reducir el gasto de ancho de banda lee este artículo y ajusta tu registro de windows para que la ventana de TCP reciba paquetes de un tamaño más coherente.
Optimizando el ADSL.
It is possible your PC is not optimized for broadband speeds.. and if you look
around on the net, you will find a lot of software and sites devoted to this
subject. The two most common network settings mentioned are MTU, and RWIN.
MTU (Maximum transfer unit) and RWIN (receive window) are actually nothing magic,
but the tweaking of these settings and the reasons behind the tweaking are
rarely clearly explained.
So, here is the skinny on ensuring you are getting the most out of your DSL line
under Windows 9x.
1. RWIN (receive window) is the single most important value, yet oddly it
is also the one thing they have still left out of the new networking control
panel! This is the ONLY setting you need to check or adjust to ensure maximum
download speed. Let me repeat that. RWIN is the only setting you really need
2. TTL and other parameters you may have seen mentioned on the web, such
as MTU and "black hole discovery", are esoteric, and do nothing for
average speed. Do not believe anyone who swears that TTL or "black hole
discovery" options made any speed difference. The default of 32 for TTL is
more than sufficient for years to come and possibly for ever – newer high speed
networks are tending to even decrease average hop counts since traffic over them
can be encapsulated and only see one hop.
MTU refers to the maximum transfer unit, the default packet size your PC will
start to use when sending data. You can optimize MTU for a specific server, but
it may not be right for other servers you visit.
For MTU and RWIN, rather than operating on the registry directly, you may like
to try this utility: Rob Vonk’s
EasyMTU. This allows view and resetting MTU and Rwin easily. When using
EasyMTU, do not take any notice of the dialup recommendations it has built-in.
How do I optimize TCP/IP for broadband connections?
.. By Tolunay
The most significant parameter for TCP/IP tuning is the TCP Receive Window (RWIN).
Most other tuning attempts usually do little or no benefit and may actually
cripple proper TCP/IP connectivity as exemplified by so called MTUTweak programs
that aim to optimize the line for dial-up use. If you have previously used one
of these programs, I suggest you remove the registry changes done by them.
Typically, these programs lower your MTU (maximum transmission unit) to 576,
reduce TCP Window Size to as low as 2144 (an absolute no no for broadband
connections), Disable Path Maximum MTU discovery (when this is diabled windows
use MTU=576). After cleanup download one of the following registry files and
double-click to import it to the registry. You must reboot to get
registry changes effective.
Note that except Window 2000 the default for RWIN for Windows family is ~8KB.
Windows 2000 uses ~16KB as default RWIN.
entries from here:
|OS||Small (16KB)||Medium (32KB)||Large (64KB)||Huge (128KB)|
* For Windows 95 with Winsock 2.0 or DUN 1.2/1.3 update use Windows 98
** Windows 95 (without Winsock or DUN update) or NT does not support RWIN >
*** Use a user account with administrative permissions to be able to change
Experiment with different RWIN to find the best setting for your connections.
Remember to reboot after each change and test with a site that is typical site
that is 10-15 hops away as RWIN depends both on bandwidth and latency
characteristic of the line. Making RWIN too large may reduce throughput
especially on a line experiencing packet loss. When the line is experiencing significant
packet loss RWIN may need to be reduced even further. This is because smaller
RWIN size allows for faster recovery of lost packets.
If you would like to customize the window better please read "How
Large Should the TCP Receive Window be?" section first. Then edit the
registry file maching your OS using a text editor such as Notepad and do the
Windows 95: Find the following line and substitute RWIN for xxxxxxxx
as 8 digit hexadecimal number. You may use Windows Calculator (in scientific
mode) to convert decimal number to hexadecimal number. Remember to prepend 0’s
to make value 8 digits long.
Windows 98: Find the following line and substitute RWIN for nnnn
as a decimal number.
Windows NT/Windows 2000: Find the following line and
substitute RWIN for xxxxxxxx as 8 digit hexadecimal number. You may use
Windows Calculator (in scientific mode) to convert decimal number to hexadecimal
number. Remember to prepend 0’s to make value 8 digits long.
Why does tuning TCP Receive Window improve throughput?
TCP is a reliable communication protocol. As a result, sender expects
Acknowlegement (ACK) packets from receiver to make sure packets are delivered to
destination and are free of errors. However, as sending one packet and waiting
for ACK is rather inefficient, a window is implemented. In this scheme, receiver
advertises its RWIN size during TCP connection setup and sender keeps sending as
many packets as allowed by receive window of receiver. In other words, each
packet sent closes the window a little and each ACK received opens it up a
On a high bandwidth or high delay (or both simultaneously) TCP connection,
sender may transmit a number of packets before the first packet reaches the
receiver. Even if the receiver were to send ACK immediately, it takes some more
time for the ACK packet to get back to the sender. To optimize the throughput,
the pipe must be filled at all times and to do this sender should never stall
waiting for ACK.This is only possible if Receive Window is made sufficiently
Receive Window should be larger than bandwidth delay product (also known as
For example, for 170ms delay on a 768Kbps link, RWIN = 768000 bits/sec *
0.170 sec = 130560 bits = 16320 bytes.
Note that if either available bandwidth or the delay is doubled, RWIN would
double as well. On LAN links the delay is very small. Therefore, a small RWIN
would be sufficient. However, effect of insufficient RWIN size become
particularly noticeable on WAN links. Due to relatively small default RWIN size
(8KB) Windows 95, 98, NT 3.51 and NT 4.0 throughput would suffer in above
768Kbps connection during file transfer via FTP. Windows 2000 uses a more
realistic 16KB default for RWIN. However, that too would need to be increased
depending on pipe capacity.
Well, that looks rather simple but latency (delay) is actually not constant.
It varies from connection to connection and even during the lifetime of one
connection as some IP packets may follow different routes and the heavy load on
a router in the path may cause extra latency.
Latency consists of two parts; Propagation delay and transmission delay.
Propagation delay becomes significant for links established over satellites and
transmission latency becomes significant when the packets must be forwarded over
many routers. In addition routers usually introduce more latency for larger
packets than smaller packets. Generally, heavy traffic in the pipe also
increases transmission delays.
To determine delay accurately we actually need to measure downstream and
upstream delays separately because we receive large data packets on downstream
and generate much smaller ACK packets on upstream. This measurement can be most
effectively done on the sender side. However, we can make an intelligent
guess on the receive side by using the PING tool to determine the round trip
time for big (maximum data packet sized) packets.
Windows 95/98, Windows NT 3.51/4.0 and Windows 2000 comes with a command line
tool called "ping.exe". Open a command (DOS) window and enter the
ping -f -n 10 -l 1472 host_or_IP
Use (MTU – 28) as the parameter for -l option (e.g. for ethernet use 1500-28
= 1472). See Microsoft KB article Q159211
on using PING tool to determine MTU (see More Information Section). Even though
the article is targeted to Windows NT, this portion of the article is general
enough to apply all Windows OS and the concept is applicable to other OS easily.
In short, this parameter should be the largest value that will NOT generate
"Packet needs to be fragmented but DF set." message.
Large packet delay measured using ping tool is the worst case delay, so it
sets the upper bound for RWIN. Most certainly normal delay will be smaller as
ACK packets used in return path will be much smaller and typically delayed less.
We may make a rough guess of typical delay by averaging ping times of
large (as above) and small (ACK sized) packets. For ACK sized packets use 12 as
-l parameter as in:
ping -f -n 10 -l 12 host_or_IP
Example: A 608/128Kbps DSL link with 200ms for maximum sized and 100ms for
small packet delays:
RWIN(max) = 608000 * 0.200 = 121600 bits = 15200 bytes.
RWIN(typical) = 608000 * 0.150 = 91200 bits = 11400 bytes.