Tag Archives: performance

Ubuntu 8.10 — Intrepid Ibex — is released

Ubuntu 8.10, Intrepid Ibex, is out, and available here: http://www.ubuntu.com/getubuntu

We’ve done several upgrade installs of 8.10 so far, and for the most part it’s been smooth. There are a couple of issues we’ve come across so far after upgrades.

The first has to do with a constantly-blinking, and seriously-distracting, wifi light. Launchpad bug report is here:

Intrepid: WLAN LED blinks incessantly on iwl3945 | iwl4965 laptop

UPDATE: You may have some luck with this fix (attempt at your own risk; results may vary…):


The next thing we just noticed over the last day or two, and that’s the apparently total loss of keyboard input inside a Windows XP VM via VirtualBox OSE. A couple of times, keyboard control eventually came back seemingly on its own after about twenty minutes.  Another time we were completely stuck for well over an hour and eventually gave up, killing VirtualBox. The keyboard isn’t totally dead; it’s just dead as far as the VM is concerned. You can still three-finger your way back into another shell and regain control of the machine. Mouse (and everything else) still works just fine in the VM, too; no other indications of any other problems. Seems like it might be related to the VBox Additions, but we’ve not yet looked into it very closely at all. We haven’t looked for any bug reports on this one yet.

And last but not least, if you run some sort of Active Directory-related setup, don’t have any local users, do channel bonding and maybe have a complicated RAID setup… you might want to consider not upgrading just yet, or at least bother browsing the release notes before you leap into upgrading. We read about this one; it didn’t happen to us!

You can download 8.10 here: http://www.ubuntu.com/getubuntu

Full release notes for 8.10 are here: http://www.ubuntu.com/getubuntu/releasenotes/810

All in all, 8.10 Intrepid Ibex seems to be a decent upgrade. It feels like mostly-minor tweaks and speed enhancements, and more driver support. Many included apps are updated. There is extensive use of the ‘>’ symbol in the menus, and that carat usage–in every orientation–carries over across much of the UI; almost annoyingly so in fact. NVIDIA drivers obsolete some older NVIDIA cards (like the GeForce4s), so you may need to go back to the open-source drivers and deal with being 2D-only for now. Check the release notes for most of the details.

System performance does seem noticeably better on all systems we’ve upgraded so far. WiFi signals where applicable seem stronger; all our setups are seeing more access points now than they did prior to the upgrade.

We have not yet done a squeaky-clean install of 8.10, nor have we tested a current LiveCD… but will soon.

Now if we could just get those blinking wifi lights to stop. b.. l.. i.. n.. k.. i.. n.. g.. .. .. .. .. It’s really, really distracting.

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, 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:

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.