A friend of mine needed a little story write-up, with pictures, of computer hardware history in the last 20 years. I Google’d to find something like this, and couldn’t. Most hardware history articles are something along the lines of “Computing began in World War 2 with supercomputers and has progressed steadily to personal computers and now to laptops”. Not really the granularity that he was looking for. I decided to take the photos myself – I have nearly 20 years of equipment in my house. That’s kind of a side effect of discovering Linux in the mid 1990′s – it ran on that hardware then, and still does I’ve decided to post the article, with pictures, here, so that it might be useful to someone else on Google. Take what I’ve written with a grain of salt though, it wasn’t written to be a scientific journal article, only as a quick overview!

CPU’s

Top to bottom, left to right
Intel 486 Overdrive, Intel Pentium 1, IBM Cyrix
Pentium 2
Intel Celeron, AMD Duron, Intel Pentium 3
Pentium 4 (1st generation – 400Mhz FSB), Pentium 4 (3rd generation – 800Mhz FSB)

Note the increase in physical packaging size as technical CPU advances exceeded the fabrication technology advancements and economically feasible. The initial Pentium 2 was not able to be manufactured in a single chip that was small enough and had enough pins to draw power with, and it was uneconomical to construct it out of a single chip that it was feasible to do at the time. Within 24 months, fabrication technology had caught up, and CPU’s were moved back to a single chip form and made smaller. Current (2009 Q2) Core 2 Duo’s are smaller than Pentium 4 chips. The size of the chip is directly proportional to the transistor size and number of transistor used. The number of transistors has been growing in accordance with Moore’s law, and the fabrication technology has been shrinking accordingly. The smallest transistor size of a current (2009 Q2) CPU is 45nm (mass production debuted late 2007 by Intel). The shift to 32nm is road-mapped for 2009 by Intel.

The transistor size has a direct impact on the thermal output of the CPU which peaked with the Pentium 4 at approximately 150 watts (Pentium 4 3.4Ghz). Early x86 generation CPU’s did not require heatsinks (286, 386). The 486 and Pentium required passive cooling. Higher model Pentium’s required active air cooling, which has been the norm ever since. Thermal dissipation was one of the key inhibitors in maintaining the increasing performance of single core computers.

HDD’s

From left to right: 3.5”, 2.5”, Solid state
Not shown: 5.25”, 1.8”

HDD’s have been a very slow moving technology from the physical packaging outset. Manufacturers of consumer are notorious at maintaining upwards interface compatibility. Almost all 3.5” drives are IDE, and the original IDE drives manufactured circa 1990 will still work in the most recent IDE computers of 2006 (but not vice versa). The consumer market changed the physical interface to SATA circa 2003.

The SCSI technology used in server computing (not shown) uses the same packaging, but has undergone several physical interface changes similar to CPU socket changes.

The fast moving trend is to make platter size smaller. 5.25”, 3.5”, 2.5” – now common in server computers – and 1.8” (now common in laptops). The platter size shrinkage has been done without platter storage capacity shrinkage, resulting in an increase in aureal density of the platter and corresponding throughput increase as reading the same physical size off the disk results in more bytes being read than before.

The long moving trend is away from mechanical devices to solid state devices, as fabrication technology for high-density storage microchips has become economically and technologically feasible in sizes large enough to be useful to end users (64G solid state devices are currently available as options in mainstream computers – 2009 Q2).

Motherboards

Bottom: Intel 468; CPU embedded on mainboard
Top, left to right: Pentium, Pentium 2, Pentium 3

Note the change in peripheral interfaces: ISA only in the 486, ISA / PCI combination in the Pentium and Pentium 2, and PCI only in the Pentium 3. Pentium 4 introduced PCI express, and current (2009 Q2) dual processor boards are moving to PCIe only. Mainboard manufacturers are evidently good at maintaining clear upgrade paths, maintaining backward compatibility with the previous generation of peripheral connectivity so that the user does not have to upgrade the whole system.

The other two user-replaceable componentry that has changed over the course of mainboard history is the CPU socket and RAM socket. This has been necessitated by the change in physical CPU and RAM interface presentation. The RAM interface changes are generally driven by changes in technology, while the change in CPU circuitry is often pre-emptive by the manufacturer. This was evident in the Pentium 2, when socket and slot versions were available: the physical interface was different, but the logical interface was not. Converters were made for mainboards so that newer socket processors could be fitted to older slot mainboards.

As of the Pentium 2, the power interface also changed. 386, 486 and Pentium mainboards operated using AT connections. The Pentium 2 introduced the ATX power specification that changed the physical interface. The Pentium 4 introduced an additional 12V power connector to allow the processor to draw extra power: The Pentium 2 power draw was in the area of 25 watts; the Pentium 4 reached 150 watts. Dual processor mainboards used an updated ATX specification that combined this 12V connector into the main power connection, and this is the currently (2009 Q2) used power specification.

Each physical change in RAM and CPU that has required changes to a mainbaord have also impacted the bus layout. Chip integration technology has also resulted in only 2 main chips on mainboards, starting with the Pentium line up. Note how the 486 mainboard has several prominent chips on it, while the other mainboards only have 2 (plus the CPU). These two chips are designated the south and north bridge chips after the logical location proximity to the CPU. The Northbridge interfaces between the CPU and the Southbridge, as well as providing the memory management chip and AGP interface control (and thus including a GPU on motherboards that include it). The Southbridge is responsible for peripheral I/O (USB, Serial, Parallel (ports), DMA, PCI, RTC). These chips are also usually located in the same physical proximity order as the logical proximity by mainboard designers in order to minimise physical bus tracks. The Southbridge is often near the peripheral ports, while the Northbridge is between the CPU and RAM: On the Pentium 2 mainboard shown, the Northbridge is just under the heatsink of the CPU, the Southbridge is right next to the PCI ports.

RAM

Top to bottom: EDO RAM SIMM, SDRAM DIMM, DDR SDRAM DIMM, DDR SDRAM SO-DIMM (chips in chronological order)

Physical chip size of RAM has increased since the 486 era. The chip density has increased faster, however, and thus the larger physical size is representative of an increase in size of an order of several magnitudes. Typical sizes per memory module were:
72pin EDO SIMM: 1 to 4MB
SD DIMM: 16 to 128MB
DDR DIMM: 64 to 512M (1st generation), 256 to 1G (2nd generation), 512M to 8G (current – 2009 Q2 – generation)

Small form factor DDR RAM is logically the same as normal DDR RAM, but uses smaller physical interface. Note the chip size is the same on the normal DDR RAM as it is on the full size DDR module. Small form factor modules only include 2 chips per side of the module, and thus have a smaller capacity than their full factor counterparts: The current (2009 Q2) maximum small form factor DDR RAM capacity is 4G, compared to 8G in the full size form.

The interface technology of RAM has changed with each generation, but the general construction has not. Memory is still accessed by row / column blocks of bits. Initial Single Inline Memory Modules had a single set of electrical contacts and required installation in pairs in order to present a logical memory banks. Dual Inline Memory Modules had two sets of electrical contacts; one per module side. This is the physical interface.

The Extended Data Output interface on SIMM’s brought burst mode technology. Synchronous Dynamic technology was introduced in the mainstream in the mid 1990′s coinciding with the Pentium 2. This interface allowed interleaving between modules to enable faster throughput. Double Data Rate SDRAM simply involves changing the way the electrical signal is delivered / interpreted; it transfers data on the rising and falling edge of a clock cycle. Other than that, it is the same as the SDRAM that was developed in the mid 1990′s.

Decreasing transistor size and more efficient chip layout software has enabled RAM chips to benefit from decreased latency (access time). Typical access time on a SIMM was 70ns+, current (2009 Q2) latency is in the order of 5ns. Latency has been under 10ns since DDR RAM was introduced circa 2001 however, and this reveals that improvements in RAM technology are stagnating compared to processor improvements.

Well I’m sad to say that I am terminating my efforts to run Splunk on FreeBSD (for now). Why? For some reason, my home installation of Splunk has stopped recording data delivered over the configured network ports. I presume something has become corrupt, because the connection is made successfully, it is just not recorded in Splunk (according to live tail). I did try to upgrade and discovered 2 thigs.

Firstly, the latest FreeBSD stable edition is 7.2 and Splunk are STILL only offering their application for 6.1. This is to do with the threading issue that has changed between 6 and 7, but 12 months after the OS release they still don’t offer an application for it, meaning we still have to hack the OS a little bit to get the application to work. That’s unsatisfactory vendor support IMO.

Secondly, their upgrade instructions don’t really work for FreeBSD. They suggest simply installing the package over the top of the existing package. FreeBSD doesn’t allow that unless you force it (pkg_install -F). When I tried forcing it, the install terminated silently. I mean, pkg_info doesn’t show that it is installed, starting Splunk reveals it is the old version…it just didn’t install. And there is no error saying why.

So, I can’t upgrade, and a complate reinstall means I have to hack the app to get it working agian. I just can’t be bothered. When I move to virtualization I’ll have a more powerful server and I’ll reinstall the Linux version of Splunk. At least they are supporting the stable kernel on that!

PC-BSD is supposed to be a version of FreeBSD that is tailored for use as a Desktop OS. Some of my experiences so far:

1. Installation is excellent, and fast (20 mins). No need to have an internet connection, and not many questions in the installation. Everything worked with autodetection on the reboot of the installation, so this is all good.

2. Updates provided through an automated system (which works). This means the main applications that I use for desktop use (Firefox, OpenOffice, VLC) are all easily updatable. This is good because OSS moves very quick, and by the time any distribution standardises on a release, updates for half the software already exist. The downside is that there is still a reasonable amount of software that I use that is not in the PCBSD format, but I’m sure that will change as they get bigger and add more packages.

3. Bad printing support (for me). This is a BSD problem, not a PC-BSD problem, but ultimately it makes it a bit difficult to do “real” work on my PC – I can’t print it! I have a Samsung CLP-300 which has Linux drivers from the manufacturer. Additionally, the OSS world has support for it in the SPlix software package (Samsung Printer Language software). Unfortunately, the SPlix version in FreeBSD ports is horribly out of date – it hasn’t been updated since the end of 2007, and is still using version 1.x. Version 2.x is out. This wouldn’t be such a problem except that printing on the CLP-300 with the 1.x driver fails with the error: “Filter rastertospl2 for printer CLP300 not available: No such file or directory”. This is a known error in 1.x that was a problem for many Linux distributions, and they promptly updated it. FreeBSD, for some reason, has not.

4. Although everything worked out of the box, the graphics performance is sub-par. I have an ATI HD 2900XT, and ATI don’t produce FreeBSD drivers. nVidia do, but only 32 bit. So I guess I can’t use a video card in my computer. Oh well Seriously though, it works, but there is no 3D hardware acceleration in the open source drivers for the more recent cards. This means that all the OpenGL effects used by the fancy GUI desktop really put a strain on the CPU (30% of both my cores are being used JUST to draw graphics at the moment).

[Update, 16th June] 5. When you shutdown uncleanly (i.e. without actually initiating it from the desktop and waiting for it), upon reboot PCBSD makes you wait for the file system check. Also, it doesn’t actually tell you the status of the file system check! Linux Ext3 makes you wait as well, but at least it tells you thae status so you have an idea of how fast it is going / how long it has to go. Also, FreeBSD has the capability to background the file system checks (I have this set on some other actual FreeBSD test systems), so I don’t know why PCBSD chose to do this. Maybe just for safety…

I dist-upgraded my Intrepid machine to Jaunty a couple of days ago. I thought it might break something, boy was that an understatement. As is usual on dist-upgrades for me (Debian and Ubuntu, for the past 5 years or so), the upgrade doesn’t complete the first time it is run. It runs into dependency issues. Running it multiple times consecutively resolves them (must be some race conditions, sigh). Oh I should mention the ONLY reason I was performing the upgrade is that I wanted access to OpenOffice 3. It’s been out since the beginning of the year, but Ubuntu have only just added it into their distribution. It’s MUCH better than 2.4.2, and I’d been running it from the binary distribution that I’d downloaded. There were no problems working inside OO3 from the binary distribution, the problem is, nothing knows that it exists. The install paths for the binary are quite different to Debian’s (and thus Ubuntu’s) and Firefox refuses to acknoledge it as a possible application for anything, and the Thunar file manager conveniently never remembers it’s location when I “open with”. It was driving me nuts.

So after the first dist-upgrade, my X-server broke. Now, that was kind of expected as I’m using a proprietary ATI driver. But that wasn’t what broke. What broke is that my mouse no longer functioned in X. GDM would start, and I just couldn’t move the mouse. I thought it might be related to the partial upgrade, so I run the dist-upgrade again, and also restarted for good measures. The result? The computer failed to boot. It seems that in the current stable version of the Kernel for Ubuntu, 2.6.24, there is a bug with some chipsets that causes the SATA drives not to be recognised. Thus, there is no drive for the kernel to boot from. Now, dist-upgrade is not intelligent to realise that the kernel is a core piece of software and perhaps that old kernel boot image should be kept and marked as “old” (as with what happens when you follow the kernel.org instructions for the source), so I was left with an unbootable system.

With the help of a rescue CD and chroot, I upgraded to the unstable kernel, 2.6.28, and it picked up the chipset properly again, and booted. However, the X problem remained. I fiddled with the X configuration, moved my mouse to a different port, no avail. Eventually I decided to just upgrade the xserver-xorg package and the corresponding x packages to ensure that they installed correctly. At first I couldn’t do this because the installation of the unstable kernel does not automatically install the kernel modules packages, and so I had no ethernet. I had to do the rescue CD + chroot trick to install the linux-modules-2.6.28-11-ubuntu package. After this, I still had no ethernet. For some reason it was not autoprobing my ethernet device deiver. Grr. I eventually also found out that my ethernet device, the Attansic / Atheros L1 is under the Firewire bus. I have NO idea why. Inserting the firewire module results in the ethernet driver loading up straight away. Eventually I just added the ethernet device module, atl1, to the /etc/modules.conf to force the system to load it at startup. Phew, at least it worked, now I could update X!

The result? Now when I start the XServer, it crashes immediately. Not the XServer, the whole computer. I get funny images on my monitor, as if it used the graphics card incorrectly, and then it crashes immediately.

So I finally made the decision to switch to FreeBSD as a desktop operating system. I lose the ability to run VMWare but that’s about it. I chose PC-BSD because it has commercial support, which I thought would make it more stable and configuration-friendly (it does). In order to get the OS installed, I booted off the XUbuntu 8 live CD that I had and used GParted to remove my old Linux partitions and combine them into a big partition for the new OS. I left the data partition (a 160G partition containing my data, always nice to keep the OS and the user data separate). When PC-BSD installed, I didn’t notice the parition size didn’t match up to what I’d just created. The result? PC-BSD thought that it was on the whole area of the disk; the parition pointers were all wrong. I guess GParted broke something. I should have just used fdisk :/

Now, I managed to get this fixed, with Acronis tools and a reinstall of PC-BSD. I got everything sweet and began to unpack some archived data off the data parition. It failed, crashed the computer, and reset the power. Upon reboot, PC-BSD wouldn’t mount the ext3 partition anymore; it complained of a bad superblock. I’ve had this before, it usually just means the drive needs and FSCK because something went wrong in writing to it. I booted back into the XUbuntu live CD, ran FSCK and hey presto, MANY illegal block errors. I left it running for about 6 hours (fsck -y) and came back to find that it had removed all files, and recovered about 60G of the 160G in the lost+found directory. My best guess is that GParted screwed the partition pointers up, then PC-BSD wrote to some wrong areas of the parition so that when it mounted the ext3 data patition, the inodes were broken, and the FreeBSD implementation of the code for ext3 couldn’t cope with it and made the problem worse. I’m still recovering my data, and I realise I have lost about half of it. It’s ok, because it was mainly used as a buffer drive, but I don’t have a full list of what is gone which is annoying. I don’t think I’ll be going back to Linux for a while. In BSD they are quite good at making sure applications are quite stable before putting them into the ports area (much better in my experience, and faster – they had OO3 ages ago!!).

I was reading the Whirlpool Broadband Survey 2008 Report tonight, and I found one section interesting. When measuring how long it took to get the right person on the phone (i.e. tech support person for tech support, sales person for sales who can actually sell you the right product etc.), how long did it take. Look at the first column. 24% of calls to Telstra resulted in an average of 20 minutes waiting, and 26% of 10 minutes waiting. Thats an average wait period of 15 minutes for 50% of calls to them. That’s also insane.
I had to break the table into 2 parts to fit it into this WordPress theme, I hope it still makes sense.

When calling customer support, how long did you have to wait on the phone (or talk to an operator) before you spoke to the right person?

One project I have had recently is to compile a live CD with the open source flight simulation game FlightGear. Since Windows has licensing issues, the obvious choice for me was to go Linux. Linux also lends itself nicely to Live CD’s as people have been doing the development for about 10 years now (Remember the first edition of Knoppix!!!). Morphix was a commonly used platform a couple of years ago, but it seems not much has been done in the way of maintenance of the actual program or documentation since the end of 2006. This seriously inhibited my ability to get a LiveCD working the way I wanted it to with Morphix. Specifically, it annoyed me having to split main modules and mini modules as they never seemed to operate the way they were supposed to on the actual live CD.

I have used Slax in the past to build rescue CD’s, but I really would prefer something that is based on the Debian style of package management (Morphix is based on Knoppix which is based on Debian (phew!)). In my research I stimbled upon the Debian Live movement, an official movement by Debian to make Debian LiveCD’s. The tools that they make available seemed unwieldly at first, but that’s just because the man pages are kind of bad. With the help of lots of hard disk space and a free license for VMWare Server, I was able to figure out how things worked. And work it does, very well.

Ok let’s bring this back to the topic heading. Great, I can make a maintable live CD based on Debian and port FlightGear into it. The problem is, getting proper 3D acceleration. I don’t use 5 year old hardware. The oldest hardware I’ll be running this on is 18 months. That means nVidia 6xxx hardware at the oldest, and Radeon 5xx hardware. There isn’t very good support for that in Debian Stable (Etch – 4.0). My next project was thus to import the ATI and nVidia proprietary drivers into the CD. The way I found to do this was to copy the driver setup package onto the live CD, boot into the LiveCD, compile the libraries, then copy the libraries off the disc and remaster the disc with the actual compiled libraries. This actually worked and I was able to insert the kernel module. However, the X11 module for ATI did not seem to want to talk to the Kernel module even though it inserted correctly, which meant that 3D acceleration was still missing. Also, the nVidia GLX module in X11 kept inserting automatically when it was present, stopping the Mesa or FGLRX module from inserting. Sigh. In other words, it seems that it was going to be a pain to get working and a pain to maintain.

Ok here’s where the gaming gets interesting. Because I was searching for Linux LiveCD information and getting proprietary 3D drivers to work, I discovered 2 live CD distrobutions that are built explicitly for this purpose. live.linuX-gamers.net and the Supergamer live CD. live.linuX-gamers.net is built around open source games, but really does showcase some good native Linux games that have been built. Supergamer is built around a showcase of games that were available commercially for Windows and have been made free for Linux in one form or another, and so really showcases what a LiveCD can do. And it does appear to use the proprietary drivers. If I had the master build files, I’d strip the games out of it and put FlightGear in, but as it is it’s just the ISO that’s distributed and I don’t want to spend time in email conversations to get information…if they don’t want to make it publically documented at this point then I’ll just wait. It’s still a great effort though (see this great review with screenshots)!

Heighdon Layton is my cousin-in-law. You know, your step-parents-siblings-kids. I mean, my step-mothers-brothers-son. I had to actually Google to see what people thought the difference was between step mother and mother in law…It’s kind of silly really; they’re both legal relations (as opposed to blood) but they mean different things. Sigh.

Anyway Heighdon is on the right with his pants down around his ass and my other cousin-in-law is Brett Roberts on the left. The photo looks a bit like they’re about to start a fight, but it’s just a good example of the photo not depicting the reality properly (I’d make good papparazi no?!?

They asked me to write something about them. Heighdon Layton is the motocross king of Perth (or something, right?). Brett Roberts is the ladies man of Quinns Rock (or something else). Now bring on the Google goodness YEAH!

I took some time out the week before Christmas to go down to Albany at the offer of some friends who were leasing a holiday home down there. The place is quite nice, and I think a 5 day stay for me is just right. I go a bit stir crazy if I don’t have work to do after a little while!

When I found out that one of the guys had not been to Bluff Knoll, we both felt it would be a good idea to take a trek out there (this was yesterday). It’s about 100km out to the Stirling Ranges where the mountain is so a little over an hour of driving. It’s a 3km or so trek up and around the mountain, and it took us just over 2 hours to reach the summit. We picked a great day to do it, it was sunny and all. Today is very very overcast in Albany!

For some reason, when we got to the top, we couldn’t see a sign to say “Bluff Knoll.”. I climbed the mountain about a dozen years ago and I know there was a sign. We went to the very very top, nothing was higher than us, so we certainly didn’t miss it. I feel a bit shortchanged not being able to take a photo of myself at that sign again though! Oh well, it was a good climb, being at the highest peak in the South West at 1.1km elevation.

I use Ubuntu on my desktop box. I downloaded a backup script to trial. I thought, my work is on my desktop box, and I want to backup it up to a remote machine. So I downloaded the script to my desktop box, configured it, ran it, and it didn’t work. I couldn’t be bothered checking the debug output, so I just turned on the email error messages and sent the errors through to my email for me to review.

No email arrived. I thought, ok, maybe I’ve messed up the DNS on my local network for my mail server. Nope. All good. I also tried sending to a different account, but no email arrived. I checked the mail queue, to see if it was being sent out via the local SMTP as is often done, only to find that Ubuntu did not include an MTA!

Linux with an MTA is just not Linux. It’s just silly.