
Fix TCP slow-start without a kernel patch (for faster page load times) - ck2
http://blog.habets.pp.se/2011/10/Optimizing-TCP-slow-start
======
0x12
This is not as hot as it seems. The RTT quoted (50 ms) is ridiculously slow
for most broadband connections.

If you really do have a connection that slow then yes, you can improve matters
a bit by adjusting the window sizes, here is an article that goes in to a lot
more detail:

[http://www.speedguide.net/articles/the-tcp-window-latency-
an...](http://www.speedguide.net/articles/the-tcp-window-latency-and-the-
bandwidth-delay-2678)

Also, you normally don't control the sending side, which can overrule any
window size you request.

Tuning TCP has its uses but client side tuning is very limited in effect by
itself, clients and servers tuned to be optimized for their particular
connection can see some gain.

~~~
nknight
> _The RTT quoted (50 ms) is ridiculously slow for most broadband
> connections._

The speed of light would like a word with you.

Even if you had a "straight" link across the surface of the earth, the
information transited at 100% of c, and there were no processing/equipment-
induced delays, New York to Los Angeles is ~26ms round-trip.

Unfortunately, the speed of light in fiber is not 100% of c, it's more like
66% of c, so your round-trip time is more like 40ms.

This still assumes zero congestion, zero equipment delays, and a direct A to B
path. In practice, you will never have any of those.

In practice, I get ~80ms from the SF Bay area to New York on an atypically
fast (for the US) connection.

~~~
0x12
He's doing this on a fairly local setup.

On similar distances/hop counts to the ones described in the article I get ~15
ms.

He's in Sweden and his host is in Stockholm.

If you test with google, the you have to take into account that google has
'points of presence' all over the globe, so if you test using 'google.com'
their DNS server will hand you an IP that is physically close to you which
will result in fewer hops.

~~~
powertower
> google has 'points of presence' all over the globe, so if you test using
> 'google.com' their DNS server will hand you an IP that is physically close
> to you which will result in fewer hops.

For anyone intrested, it's called "Geo DNS".

On the other hand, the Google public DNS (IP: 4.2.2.1) uses "anycast" routing.
You use the same IP address range no matter where you are located and the
magic happens using BGP (a router protocol).

<http://code.google.com/speed/public-dns/faq.html#anycast>

~~~
0x0
Nitpick: 4.2.2.1 is not owned by Google, it's owned by Level3. Google's public
DNS is at 8.8.8.8 (and 8.8.4.4)

------
ck2
cached copy of the post article (seems down now)

[http://google.com/search?q=cache:http://blog.habets.pp.se/20...](http://google.com/search?q=cache:http://blog.habets.pp.se/2011/10/Optimizing-
TCP-slow-start)

A little history for those wondering what this is about

<http://blog.benstrong.com/2010/11/slow-start-follow-up.html>

[http://blog.benstrong.com/2010/11/google-and-microsoft-
cheat...](http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-
slow.html)

<http://lwn.net/Articles/427104/>

<http://bits.shutterstock.com/?p=74>

<http://research.google.com/pubs/pub36640.html>

[https://docs.google.com/gview?url=http://research.google.com...](https://docs.google.com/gview?url=http://research.google.com/pubs/archive/36640.pdf)

[https://docs.google.com/gview?url=http://www.ietf.org/procee...](https://docs.google.com/gview?url=http://www.ietf.org/proceedings/78/slides/iccrg-7.pdf)

------
ck2
Question for the advanced: with that kernel version warning, since CentOS
4.8/4.9 is stuck at _2.6.9-023stab053.2_ does that mean I can definitely not
use this workaround?

The .9 seems to imply not, but I am not sure how to interpret all those
versioning extensions (ie. stab053.2)

~~~
nknight
It's impossible to state with absolute certainty without going through the
patches that have been added by Red Hat to your kernel, but I'd be surprised
if something like this from so far down mainline got backported. 4.x is pretty
old, and the regular life cycle ends early next year.

~~~
ck2
Drats, even CentOS 5.7 is too "old" or at least not up-to-date with the core.

CentOS 5.7 is _2.6.18-028stab089.1_

~~~
udp
I noticed the age of the stock CentOS kernel the other day when trying to
build something that used timer FDs - 2.6.18 was released in _2006_.

~~~
ck2
To be fair, CentOS 6.1 is current - and has a "continuous release" repository
too.

But those (like me) running old installs on CentOS 4.x are pretty much stuck
though unless they are running fully dedicated and can do an unofficial
upgrade (tricky stuff).

~~~
sciurus
The "continuous release" repository provides individual updates from RHEL 6.2
as CentOS finishes repackaging them, rather than requiring you to wait until
they've repackaged all of them. It still won't get you a kernel newer than (a
heavily-patched) 2.6.32 from 2009.

