The longevity of old hardware

October 2, 2006

In a bittersweet moment a week and a bit ago, I finally decommissioned my SGI R5K Indy. We got the machine in the summer of 1996, so it has been provided faithful, trouble-free service for just over ten years. That's impressive longevity, especially for the hard drives.

It was a pretty good machine when new, basically the top of the line of SGI's basic workstations; as a peon sysadmin, I was lucky to get it. I spent several years using it as my primary workstation and enjoying the various nifty SGI bits (including its video camera) before we moved from SGI servers to a PC and Linux environment; after that it lingered on in the background, still doing various bits and pieces.

(Even today, looking at it makes me feel nostalgic, a feeling which is helped by the distinctive case design and the SGI marbling on the monitor; SGI machines were never generic beige boxes. Even if the R5K Indy was not the best thing on the block, SGI worked hard to make it feel cool and sexy. A part of me still regrets that SGI ultimately lost to the PC juggernaut; sure, I get a lot more performance, but it lacks the pizzazz and personality.)

Part of the bittersweetness is that the Indy is probably the last of my machines that will be in service for such a long time. Not only am I letting go of a machine that's been running for ten years, I'm letting go of the idea of having hardware that I run for ten years. The world is a different place now; major OS and architecture transitions seem unlikely, disk capacity keeps growing rapidly, and my current machines instead have a kind of serial immortality, where the important thing is the data not the particular hardware it lives on at the moment.

One of the semi-impressive things (or alarming, depending on your perspective) is that the Indy has been running the same operating system for those ten years. I installed Irix 6.2 on it back in 1996, and it has run it ever since; we never upgraded.

Sidebar: the Indy's hardware configuration

The machine has a 150 MHz R5000 MIPS CPU with two 32K L1 caches (I and D), a shared 512K L2 cache (still a common size), and 64 MB memory. I think we bought it with a 1 GB internal SCSI disk; in its current configuration, it has a Micropolis 4743NS (4 GB) and a Seagate ST32430N (2 GB), with one of them in an external enclosure (probably the Seagate). Back in the days, this was a lot of disk space.

(Even when new, there were bits that were dowdy compared to the PCs of the day; 8-bit graphics (even with multiple hardware colormaps) were clearly on the way out, and the serial port speeds were nothing to write home about.)


Comments on this page:

From 70.68.38.175 at 2007-04-13 07:22:19:

Old hardware is good in some ways - I have an Ultra5 that is acting as my main workstation via ssh. I'm planning to upgrade in the near future, but I have no idea how I will configure a new X86 machine's BIOS. I'm blind, and this causes some interesting problems when it comes down to newer hardware. I don't want to have to spend large amounts of cash on console redirection, or $300+ on a card that will connect via PCI as another video card, ETC just to get the access to my own machine that everyone else has by use of a monitor. Old hardware still wins in that respect, hands down.

Too much depends on the operating system actually coming up. I could probably get a screen reader going on the Ultra, but we still have the problem of the operating system - sometimes it just won't boot, and no amount of screen readers will help me with, say, openFirmware through the video display - or to give a more recent example - an X86 machine's bios. This is a truely sad state of affairs - is it too much to ask to dump the screen out the first serial port, to the first few sectors of a floppy or other output medium upon pressing a key in the BIOS setup or POST? I wouldn't need a LOM like is included in some servers; I just need an alternative to dragging out a monitor and trying to position a webcam so that people on the internet will be able to read what should really be accessible from the start. Tyler, http://allinaccess.com

Written on 02 October 2006.
« The advantage of vendor packages
Some numbers for modern disk performance »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Oct 2 23:31:11 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.