>From: "Pete" <speed@advcomm.co.nz>
>I see on IHUGs site (http://www.ihug.co.nz/ultra/support/rwin/index.html)
that
>they offer pre-made registery hacks to allow you to change TCP settings
>(presumably things like MTU) to speed up your Ultra connection.
>They put a nice file in there for Windows users, but don't explain what
changes
>they are making so I can do the same to the TCP stack of my Linux box.
>Has anyone else out there changed the MTU etc of their Ultra connection and
>could explain how and why (or just how :)?
On linux I dont know how, I do know why, but I can't avoid a lengthy
explanation (sorry).
The setting that is being tweaked is the TCP receive window, not the MTU
which is Layer 1/Layer 2 attribute. I think Windows Secrets covered this.
Most of the media blurb you read about this is (excuse my french) total
crap. The Windows default (usually 8k) is designed for LAN connection
speeds, thus a tweak on a 56k modem may help, it may also halve the rate at
which some downloads occur if conjestion control kicks in.
You can calculate the theoretical maximum download rate, for a given rcv
window (rcvwnd) from round trip time (rtt) for example (ball park figures):
rtt = 50ms
rcvwnd = 8000 bytes
tss = 1000 bytes (TCP segment size, irrelevant)
Max rate = (rcvwnd/tss) * (1000/rtt) * tss
= (rcvwnd * 1000)/rtt
= (8000 * 1000) /50 = 160,000 bytes/sec or about
2Mbit/sec.
You will see from the formula that the larger the round trip time, the
larger the rcvwindow must be to maintain the same data rate. Round trip time
is NOT ping time, ping uses symetrical packet sizes, TCP downloads have
asymetrical data rates, there is a world of difference. From the above you
can see that an 8k window will not govern download rate on a 2Mbit link
unless the rtt exceeds 50ms and will not govern a 512k link if rtt is less
than 200ms.
A change of rcv window would have very little effect on Web browsing as each
download is only a few KB (less than one rcv window) and TCP slow start
would be the algorithm throttling the connection for the duration of the
download.
For us here in Kiwiland an increase of rcvwnd may improve large file
download speeds from overseas because of slow rtt caused by "speed of light"
issues. Unfortunately increasing rcvwnd can result in routers dropping
packets if they exceed packet queue limits, if this occurs TCP will go in to
conjestion control which will immediately govern the rate at one half of the
rate at which the packet loss occured (noticable on a download, sudden drop
to half the download speed).
Ultra as a medium would have some interesting characteristics, a slow
dedicated 33k upload and a shared medium for download. The rtt will be slow
compared to a LAN thus a tweak of rcvwnd would probably help if rtt is over
150ms.
I disagree with the settings in their reg files, an increase from 8k to 16k
would change the bottleneck from rcvwnd to the physical link, any higher
values just result in the server spewing out packets that get dropped
somewhere and TCP goes into half speed conjection control (the reg files
appear to set the rcvwnd to 130k which is closer to "lunar lander"
requirements).
If every Ultra user set their TCP window to 130k then a lot of TCP
implementations would fold into conjection control and retransmission, in
this environment a large percentage of the available bandwidth can get
consumed by TCP retransmissions; not uncommon but not good if you are paying
for every packet.
To unsubscribe: send mail to majordomo@unixathome.org
with "unsubscribe broadband" in the body of the message
Received on Thu Dec 14 12:21:35 2000