Category Archives: broadband

Cute Pictures For Time-Warner Milwaukee and Roadrunner To Stare At

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, using PingPlotter Pro showing when our internet connection was dying, over and over again, during this one download. Red, of course, is bad:

PingPlotter Pro 8p-915p

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.

ddwrt screen cap of dhcp lease

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:

2008-04-09 20:30:


2008-04-09 20:31:


2008-04-09 20:33:


2008-04-09 20:37:


2008-04-09 20:38:


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.

Time-Warner Milwaukee’s Landscaping Is FABULOUS

I’ve frequently said it’s about 100 feet of cable, but if you include the old cable, which was lying open and unburied across the back ditch to the pole for about 30-40 feet since we moved here almost three years ago, it’s closer to 150 feet or so.

Anyway, it’s ridiculous.

Cute Time-Warner Milwaukee / Roadrunner Trainwreck Pics Coming Soon…

We keep changing our minds a bit about what we want and need to say to accompany the images and connectivity data we’ve been collecting and working on sharing. The problem is the following:

PingPlotter Pro Total Data Collected To Date (And Still Collecting)

We’ve got a LOT of data–too much, almost–collected over the last month or so, all of it graphically viewable/displayable thanks to the magic that is PingPlotter Pro.

We’ve literally been tracking and sampling data on our connection non-stop for the last month, and we will continue to do so until this is resolved.

Some days there isn’t much to look at, because we’re probably out of town or otherwise not around or actively using the connection. Other times, like with any sustained download of any kind–regardless of OS, download protocol, machine, local network devices or configuration–it’s pure hell, riddled with cable modem reboots, Internet disconnects and packet-loss statistics that just aren’t acceptable, ever.

We hope to have a post up soon–with lots of pretty pictures for Time-Warner Milwaukee / Roadrunner–that shows pretty clearly what a giant suckfest this has been and continues to be. It would be great to be able to post everything, but it’s just not practical.

We’re quite willing to turn it all over to Time-Warner if they ever end up noticing and wanting it. We’re also quite willing to turn it over to the local media at this point, too. Enough is enough at some point, and we’re pretty sure we’re actually well beyond it.

And in other ‘more of the same’ news, the approximately 100 feet of cable line lying, unburied, across our backyard on our lawn continues to lie there, since January…of 2007, making this Month Fifteen of that, too. Oh, and it didn’t fix a damn thing, either. For that matter, Time-Warner Milwaukee has no record the guy ever paid us a visit that day or did anything, and he was here for hours.

It’s seriously like we don’t exist to anyone but the billing department.

We’re going in tonight to discuss our bill with the local Time-Warner Milwaukee office. We’re not expecting much but more Missing Of The Point accompanied by additional Lack of Understanding of the Problem.