NOTE: The TCP variables reported are for the transfer from the server to your client.
You can see the hops (routers) that your packets pass through from your machine to a target Internet site with the traceroute command (for Windows, use tracert in DOS/command prompt window). The route can actually vary from packet to packet, test to test, and the reverse route (return path) may not be the same. There are several traceroute servers around the world that can show you the route back to your browser. I also have traceroute servers at ORNL and at UT.
Throughput can be limited by both client and server OS's TCP window size.
The rule is, windowsize = bandwidth * RTT
For @home to ORNL, RTT is 200 ms, default windowsize for Windows is
9KBytes, which implies the max bandwidth you can get to ornl is about
360 Kbs. Most UNIX's allow the application to increase the windowsize
with a setsockopt(). For Win95/98 you'll need to mess with the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP
"DefaultRcvWindow"="32767"
The server window size for this Java tester is 8 MegaBytes (GigE NIC).
Max window used to be 64KB, but newer OS's now support window scaling,
so you may be able to request more than 64 KB.
(The remote server for this test uses a window of 64,000 bytes,
and the network interface is 100 Mbs.)
For more info on TCP tuning, visit
cable/dsl tuning
or dslreports.com tweaks
or UNIX and
Windows TCP/IP tuning tips or windows 2000
TCP tuning.
You can measure round-trip times with the ping command.
Throughput is also affected by packet loss due to congestion. Visit my cable modem testing page to learn more about the effect of packet loss on TCP performance.