The idea with this post is to (hopefully) illustrate a bit more graphically what a typical hour or so of Roadrunner broadband service is like for us right now, pretty much every time we try to really use it. Maybe it will help people understand our frustration–possibly even someone with some authority/power to Get Things Done at Time-Warner and/or Roadrunner, who knows.
A few nights ago now (April 9th), as a test, we started a bittorrent download, using Deluge under Ubuntu Linux, and proceeded to watch our connection choke, over and over again. It wasn’t at all unexpected; this is how it was for us most of last year, and how it’s been–and continues to be–still today, since early February this year when it started happening all over again, anytime we try to actually use our Roadrunner service.
The download was started around 8pm. Almost immediately, our connection started acting up, and the cable modem started rebooting.
It really is like clockwork. We can reproduce this EVERY TIME.
It’s worth mentioning again that this is NOT limited to bittorrent downloads. It’s any sustained network activity, but most specifically activity involving sustained downloading. Uploading seems to be less involved, though that’s not always true. And of course our cable modem reboots on its own even with no one around, but that could be due to any of the network-enabled equipment in our house downloading updates, Tivo guide data, or other information…or it could just be happening on its own, completely untriggered by anything on our end.
It’s also not limited by OS or any other factors inside our home. It is not our router or cablemodem. This has been tested repeatedly, with consistent results every time.
The following is a ping latency graph (pinging Time-Warner Milwaukee’s own broadband speed test site, http://speedtest.wi.rr.com) using PingPlotter Pro showing when our internet connection was dying, over and over again, during this one download. Red, of course, is bad:
As you can see in the graph above, the approximately 700-megabyte download took around an hour and fifteen minutes to complete. At 500K/sec down–which is only about one-third the advertised speed of our “turbo” connection–this download should have taken 20 minutes or so, at MOST. It was a very well-seeded file, to boot, so 1MB/sec down was definitely attainable on a working connection, meaning less than 10 minutes to download in that case.
At the full advertised 15Mbps speeds we’re paying (extra!) for, we should have had the file in about 5 minutes. FIVE.
Instead, it took 75 minutes. An hour and fifteen minutes. Our Roadrunner connection was more down than up during the 75 minutes this download took to complete. Our connection was also completely unusable for anything else during this time, of course, because it’s constantly disconnecting.
We’re paying for 15Mbps service, and in this case we were lucky to pull around 1.3Mbps, average. We’re only getting around 8-9 percent of the advertised download speeds we’re paying (extra, again) to get.
The resolution of the graph doesn’t allow you to see ALL of the disconnects/reboots, either. Some are unfortunately run together because the graph is rather tightly rendered (it was set to display a 3-hour timeframe) and the reboots were occurring very frequently, often 5-30 seconds after a reconnect.
The long red blob in the graph above is that time period where the router didn’t gracefully recover and reconnect and had to be manually fixed. Around 806pm, our router (Linksys WRT54G v2 running dd-wrt firmware) was unable to recover from the disconnects, forcing us to log into the router and issue a DHCP Renew to tickle the router into connecting properly again. That happened around 826pm.
DHCP Renew, Our New Best Friend...
Correcting this problem would be impossible to do (securely) if someone wasn’t on site to handle it, in which case the connection would be down indefinitely, awaiting manual assistance.
Sadly, this situation happens quite frequently. It might also seem easy to blame the router here, but our connection shouldn’t be dying over and over again, either. Most of the time, the router does in fact recover on its own.
So, what this means is, had we reconnected the router right away after the ~806pm reboot/disconnect, there would be lots more reboots/disconnects! The end result–a completely useless Internet connection–remains constant, of course; practically speaking, that’s all that really matters.
All this performance and speed, for only $55 a month, folks!
(excluding taxes and fees)
Around 830pm, after we renewed the router and got our Internet connection going again, we decided to start capturing some screenshots of the reboots as displayed by the Deluge bittorrent client. We didn’t catch all of them, but we did catch some. Note that many are very short reconnects followed very quickly by immediate disconnects. Also, as explained in an earlier blog posting, despite the tapered appearances on the downside of each graph, the disconnects from cable modem reboots are in fact immediate.
If you’re comparing the PingPlotter Pro graph with the timestamps of the following images, you may notice they’re by off a couple of minutes. PingPlotter Pro was actually running on a different machine than Deluge, and there is a clock/time difference of a couple of minutes between the machines. Here are the images, accompanied by the times the images were captured:
There were several more we had planned to post images for, but in the interests of completing this post, we’re going to skip them. We can provide them to anyone that wants them.
Here are the approximate date/time stamps for the remaining 20 minutes or so of reboots/disconnects:
- 2008-04-09 20:39
- 2008-04-09 20:40
- 2008-04-09 20:43
- 2008-04-09 20:44
- 2008-04-09 20:47
- 2008-04-09 20:49
- 2008-04-09 20:51
- 2008-04-09 20:52
- 2008-04-09 20:54
- 2008-04-09 20:56
- 2008-04-09 20:57
- 2008-04-09 20:59
- 2008-04-09 21:02
Connect, ramp up in speed a bit, then die. Connect, ramp up a bit, die. Rinse, repeat.
Simple browsing will often not trigger anything. Speedtests usually reflect slower download speeds, but are often such short tests that you don’t notice the connection crapping out. We suspect most people doing simple browsing would never even notice they had this problem, and it makes us wonder if others around us or on our node have similar issues and are similarly being ripped off without even realizing it.
Sooo…. that’s basically what happens every single time we try to do anything online. We are frustrated every time we go online to do anything. We don’t use our connection very much as a result, expecting to be tossed offline anytime we need it. It’s unreasonable, though, to wait over an hour for a 10-minute download, or to expect every Vonage call you make or receive will end up in a disconnect, for example. But here we are.
We’d love an answer, Time-Warner. We really would.