Ahh, that’s better!

About a month ago, I complained about Time Warner’s anemic upstream bandwidth cap on home cable modem service.  (512k!  Oh, the humanity!)

Well, a phone call to Time Warner and $10 a month later, my cap has been increased to 2 Mb.  They call this their “Turbo” plan.  (Turbo == fast, right?)

The asymmetry of my speedtest result below is still laughable, but the improvement in upstream AND downstream performance is very noticeable.  Now my uploads to Flickr don’t completely saturate the connection and more than one person can actually use the network without hosing everyone else.

I still suspect that my upstream bandwidth puts a cap on the actual download performance I can achieve.  I haven’t been able to find a rule of thumb to calculate how much upstream bandwidth is required to support a 20+ Mb/s download.

Surely there is a relationship between data coming down the pipe and the acknowledgements (or other handshaking packets) that are sent back?

Ahh, that's better.

12 thoughts on “Ahh, that’s better!”

  1. Interesting observations – so depending on who you ask, the ratio is anything from 10:1 to 100:1, and latency figures heavily into the apparent speed of the connection as well.

    Well, until Austin gets fiber to the home (http://www.biggigaustin.org/ hello, Google?) I guess I’ll have to make do with this 27/2 pipe. The good news is that compared to what I had before, these speeds are quite fine for most everyday uses.

  2. The relationship is a lot more peculiar (I’m using HSPA+ for my main connection at home, so I got to poke around it a lot.)

    Some connections require as little as 48B acknowledgement for each 1.5kB packet up (1.5kB is a typical Maximal Transport Unit for ethernet).

    This puts you in the ballpark of 30:1, roughly. (Including TCP/IP overhead).

    Now, the other question is latency. From my experience, this seems to be the limiting factor for internet enjoyment (I’m having a lot more fun using internet at work (1.5Mbit symmetrical with a 12ms ping to google.com)). Simply put, some sites are designed with a lot of synchronous dependencies.. and some browsers don’t do a good job fetching things in parallel.

    So, you end up waiting with a new GET request for one of the previous ones to complete. You can have a 160MBit down/12MBit up connection via sattelite, and it would be awesome for everything that’s optimized for insane latencies (almost nothing). Otherwise, it will suck.

    So, a plea to webmasters – we usually have plenty of bandwidth, but not enough latency. Pay attention to page load times in such cases, and test it on a high-latency connection. They are going to get a lot more popular soon. 🙂

  3. After doing a lot of FTP file transfer testing on my job, I can tell you that with unrestricted bandwidth between the server and client, I see about 10% of the download rate (from server to client) as acks from client to server.

  4. From deep south austin

    DL = 17.69 Mb/s
    UL = .27 Mb/s <- !!!
    Ping = 57ms

    I might have to upgrade. (or somehow leech yours. (firing up google earth for line of sight check))

  5. There is indeed a relationship of TCP data packets down vs TCP acks up. As I recall, typical defaults make this roughly 3K bytes down requires 30 bytes up (100:1).

    But as you approach this ratio, other factors such as round trip time and packet processing at each end begin to magnify the effect of an imbalance in up/down speeds. At 14:1 throughput ratio, your first order limit is not your uplink speed.
    ISP traffic shaping, server throttling, round trip delays, and other such internet speed bumps will be your major limiting factors.

    For most sets of conditions you might encounter, a lot more uplink speed should only give you a little more download speed.

    1. SiliconFarmer,

      Thanks for explaining this. It’s good to know my 14:1 ratio isn’t a major limitation, although it must be a measurable improvement over the 40:1 ratio I had before.

  6. Here on the arse end of the world internet wise, there were plans available with a 128k upload. That would limit the download to about 4 megs on the older windows, and on 7 (and I think vista) you could tweek it to get 8 with the receive window etc.

    Going by that, 2 megs should be plenty for a 20+ meg downstream.

    now, if only my ISP would stop shaping everything except speedtest.com tests to 40kB/sec 😉

    1. You’re not the first person I’ve talked to that has suggested that ISPs artificially boost speedtest results. Time Warner links to speedtest.com from their website, so it would not surprise me if they give priority to speedtest traffic…

      That said, I have seen some very impressive download speeds since the upgrade (>1500kb/s).

  7. The issue is prioritization of ACK packets. If the ACK packets can’t get through, then your downstream will slow. They don’t require much bandwidth, just priority.

      1. DD-WRT does offer QoS support in its tools, but I don’t feel as if it worked quite as well as Tomato’s does. It only works on WRT54G’s up to V5 though, so not an option for later models of that router. If you’re using a different router, just check the compatibility page to see if it supports it. http://www.polarcloud.com/tomato is the link.

        Anyway, back on topic… The only (slight, but more than likely non-) issue with prioritizing ACKs on any router comes with heavy Bittorrent (BT) traffic. The BT protocol sends a pretty large amount of ACKs and can, at times, affect the quality of traffic you have prioritized higher than BT. This is because they are typically prioritized extremely high to favor download speeds, which would be the reason you turned them on to begin with, right? Just turn on prioritization of ACKs and test them in all scenarios. If nothing’s affected, turn that sh*t on and leave it on! Hope that helps.

Leave a Reply