By: Brenton Blawat

Hardware View Into Building the Bad Ass Development Rig

Daniel Vanderboom has been a long time associate, business partner, and development mentor of mine. Truth be told he always has been the one to find and buy the coolest hardware and gadgets (those which I make my 08 BMW 335xi look like a manual push Tonka Toy). While he is the smartest guy that I’ve met, he always seems to have a magnetic force emanating from him rendering all computer hardware… broken.  He has had the worst luck maintaining longevity out of the hardware (not from abuse or over-clocking… just luck). For years he has been listening to my BIT Tangents about different hardware and why the majority of development systems are a joke. It has always puzzled me why a guy that is brilliant (even border-line genius) would settle for a sub-par development machine referred to a notebook computer (XPS or alike).

First to argue (and where my BIT tangent begins), new development notebooks are 2 year-old desktop computer severely limited by space and heat. Anyone that thinks a development notebook is suitable for development needs to be brought out of their isolated by mobility minds. The word development notebook ranks in with other great oxymoron like ‘deliberate mistake’ (which it is) and ‘timeless moment’ (which you will lose many of with those systems).

Let the development computing wars begin!

(To preface this section, I originally was going to post a series on hardware items such as hard disk drives, RAID, CPU architecture, RAM, etc. Due to the overwhelming response to Dan’s blog post, I’ve decided to write this article prior to my architecture posts. Feel free to ask questions about any items mentioned about architecture due to the lack of supporting blog posts.)

When Dan asked me to assist him in making the best development machine, I could finally validate my rants on computing power (besides the project being really fun). Working with Dan, I wanted to create a system that is more functional and powerful than Scott Hanselman’s "ultimate development machine". It should speak volumes that OUR benchmarks are being based off of his metrics… not Tom’s Hardware. Please don’t underestimate his development box as something other than a solid configuration… I just want ours to be the best >:)

The goal of this machine was to blend the current hardware with the true needs of a developer. Not only did I want this system to be fast but it needed to feel fast. There is a great deal to be said about the feel of the computer. Dan’s Twiddling Thumb Syndrome (TTS) is exactly what I refer to as feeling fast. If a developer has to remove their hands from the keyboard or mouse, the system is definitely not fast enough (or you’re working with an astronomically sized project).

The Systems

I wanted to provide true metrics behind the systems to provide quantifiable evidence and justifications for our claims. Tom’s Hardware always puts metrics from baseline applications such as PC Mark which mean nothing to the average consumer. I wanted to provide metrics that others could test free of charge.

Dan’s OLD Development Environment

Manufacturer: Dell
Model: Latitude D830
OS: Windows XP 32-Bit
FSB: 800MHz
CPU: T7700, 2.4GHz (dual-core) 4MB Cache
RAM: 4MB – 666MHz DDR2
Video Card: NVIDIA Quadro NVS 140M 256 GDDR2
Drive Size: SATA 160GB
Drive Speeds: 7200 RPM 4MB Cache

Brent’s slightly fast gaming PC

Manufacturer: Brenton Blawat’s Custom Brew
Model: n/a
OS: Windows Vista 32-bit
Motherboard: EVA nForce 650i ULTRA

FSB: 1333 MHz
CPU: 2.4 Quad-Core Intel
RAM: Corsair 4 GB
Video Card: 320mb NVIDIA.
Drive Size: 250gb
Drive Speeds: 7200rpm 8mb cache

Dan’s Bad Ass Development Rig (Taken From Dan Vanderboom’s Blog Posting)

Intel D5400XS “SkullTrail” Motherboard

• Two LGA 771 CPU sockets (supports Xeon DP processors)
• Four FB-DIMM slots supporting maximum 16 GB of system memory at 800 MHz
• Four x16 PCI Express 1.1a slots
• Two PCI 2.3 slots
• Six SATA 3.0 Gbit/s ports
• Two eSATA ports
• Ten USB ports

Intel Core 2 Extreme Processor (QX97750)

• 3.20 GHz (without overclocking)
• 1600 MHz FSB
• 12 MB L2 Cache

ThermalTake Bigwater 760is

• 2U Bay Drives Liquid Cooling System

Adaptec 5805 RAID Controller

• 8-Lane PCI Express
• 512 MB DDR2 Cache
• Battery Backup

3 Western Digital Velociraptor Hard Drives

• 900 GB Total
• 10,000 rpm
• SATA

8 GB (4 x 2 GB) of PC2-6400 RAM

• 800 MHz
• ECC
• Fully Buffered

GeForce 9800 GTX Video Card

• PCI Express 2.0
• SLI Ready
• 512 MB DDR3

Coolermaster Case – CMStacker 830 SE

• 1000 Watt Power Supply
• Lots of Fan Slots
• Very Modular

The Metrics

We choose to perform two types of metrics on the systems in our test which are "time" and "performance". "Time" is directly correlative to the feel of the system. The "performance" is the measured I/O of the CPU, Disks, and Memory. While many critics may argue that Windows Performance Timers are not efficient and don’t properly calculate the utilization; I don’t care. Our tests are free.

Time Metrics

The baseline comprised of a very large project referred . With Visual Studio 2008 installed on our baseline systems, the build time of the project (feel) was timed via a digital timer. This test was run multiple times from a fresh restart of the systems to ensure that any cached operations would be cleared from the systems. We ran a secondary build after the initial build to display build times after parts of the project were cached by Visual Studio in memory. To our surprise, and contrary to what Microsoft claims, the build times are faster after the project has been built one time in the running instance of Visual Studio 2008.

Performance Metrics

The performance metrics were truly the meat and potatoes of the testing. We chose to monitor the Disk I/O, Memory I/O, Memory Utilization, CPU Utilization, and CPU core utilization. We feel that these metrics would provide us with the best overall metric of the test systems.

Note: These tests were only executed on Brent’s Slightly Fast Gaming PC and the Ultimate Development rig

Stay Tuned for Building the Bad Ass Development Rig Part 2, where I explain the metrics, and further prove my Computing Theory.