
The Surprising Effect of Distance on Download Speed - ajbatac
http://blog.httpwatch.com/2008/08/14/the-surprising-effect-of-distance-on-download-speed/
======
streety
It's an interesting writeup of the effect of distance on download speed but I
would say it was more 'expected' than 'surprising'.

I would have been a lot more surprised if download speed increased with
distance.

~~~
jcl
Agreed. A better title might have been "The surprisingly significant effect of
latency on download speed"... The author starts with the assumption that
bandwidth should be the primary determinant of download speed, but it turns
out that latency is the primary determinant for some connections, due to the
TCP implementation.

~~~
ajross
That's wrong, actually. Getting high throughput in the face of high latencies
is a solved problem, and the solution is called "buffering". TCP does this
just fine, and was designed to do this from the beginning.

The problem is that the buffer isn't big enough. Standard TCP windows top out
at 64kb due to field sizes in the header. This was a lot of data to be going
over the wire in the days of 56k frame relay lines. Unfortunately, in the
modern world a connection with a round trip latency of 200ms (not uncommon)
and a bandwidth cap of 10Mbps (ditto) is going to need four times that much
data "stored" on the wire. The TCP headers don't allow for that, so the
transmitter needs to wait to send new data until the long-delayed ACKs come
back from the receiver.

As the article points out at the bottom, there is a "window scale" option to
IPv4 that allows for larger windows that is reaching common deployment, and of
course IPv6 doesn't have the size limitation in the first place.

~~~
prakash
* there is a "window scale" option to IPv4 that allows for larger windows that is reaching common deployment*

I am curious to know how common this deployment is? In most cases you are
still OS bound in terms of TCP window sizes, that being 2 in Windows and 3 in
Linux to start with. How many people do you know that really tweak this
setting?

~~~
Lagged2Death
Windows Vista supports automatic window scaling adjustments, supposedly. That
probably counts as "common deployment," but I don't know if that's what he
meant.

I used to use the freeware "Dr. TCP" program to adjust the TCP receive window
scaling on Windows computers, probably as long as seven years ago. I'm sure
that was common among professionals, enthusiasts, and on-line gamers. Less
common for Joe Six-Pack, I'm sure.

------
akd
An interesting fact that we teach in 6.033 is that of the Boston<->San
Francisco packet round trip time, half of that time is spent by light
propagating through fiber, and half of it is spent in routers.

Cisco makes some amazing products.

~~~
ajross
I can't tell if you're being sarcastic or not. Cisco routers, at least at the
level I've been exposed to, don't have particularly good switching times. In
point of fact, switching an IP header through a few-hundred-thousand-entry
routing table is something that any desktop CPU can do in a microsecond or so.
Companies like Cisco have managed to convince a lot of people that routers are
these hugely complicated devices. They aren't.

The _hardware_ side of long haul fiber networking is where the voodoo is.
Routing? Not so much.

~~~
akd
Sorry, I don't know much about the innards of routing hardware. I do know that
doing all the routing in a time equal to the propagation delay of the light is
pretty damn impressive to me.

------
pcc
This writeup oversimplifies a little. See e.g.
[http://coherentnoise.ca/blog/2008/08/response-to-the-
surpris...](http://coherentnoise.ca/blog/2008/08/response-to-the-surprising-
effect-of-distance-on-download-speed/)

~~~
llimllib
The response is much better than the original article.

------
ovi256
I recall that all TCP versions after Vegas or Reno use pipelining to increase
transfer speed. They send more than one segment before waiting for the ACK,
and this of course multiplies the transfer rate by the number of segments.
However, some TCP implementations either never initiate pipelining (it was the
case of Windows XP) or use a low limit of 8 to the number of maximum
outstanding (non-ACKed) segments, which does not push TCP to its potential.

See details here: <http://gaia.cs.umass.edu/kurose/transport/congestion.html>

------
ars
Reminds me of The case of the 500-mile email:
<http://www.ibiblio.org/harris/500milemail.html>

------
gregwebs
has anyone used the httpwatch product?

