While most of this article may seem somewhat trivial, I have found that there are many Users that don’t know how to warm/soft boot and cold/hard boot the handhelds.

Below is a quick reference guide:

How to Change the Battery in a Symbol (Motorola) PPT-8846

How to Warm / Soft Boot a Symbol (Motorola) PPT-8846

How to Cold / Hard Boot a Symbol (Motorola) PPT-8846

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.

Shown above is the basic architecture of a hard disk drive. There are tracks, sectors and heads:

• Tracks can be thought of as guides for where the data should be placed on the hard drive.
• Sectors are logical segments or groups where the 1s and 0s are stored. This allows the disk head to SKIP over data that it doesn’t need to read.
• The Head is what reads the data (1s and 0s) from each sector.  

Simple enough?

Ever wonder why hard drives are so thick? Shown above is a 3D look into a hard drive. In most modern hard drives (not solid state hard drives) are made with multiple Platters. Each Platter, in this topology has Tracks, Sectors, and a Head. 

Still Simple?

Now we need to talk about hard disk Speed. The “Speed“, as most people refer to it, is measured in revolutions per minute (RPM). An RPM is the measuring of the number of times a platter completely rotates in a 60 second period of time.

The actual Speed is a complex equation which involves RPM, Seek Time, Rotational Latency, Interface Type, and Access Time. With these individual items combined, mathematically one can calculate the theoretical transfer rate of the hard drive.

So what is the different between all of these things? 

• Revolutions Per Minute -  RPM is the measuring of the number of times a platter completely rotates in a 60 second period of time. (yes I repeated it)
• Rotational Latency (delay)- RPM and Rotational Latency are directly correlated.The Rotational Latency is an average time for the Head to read the entire track of a disk. In theory, the faster the hard drive is spinning, the less time it takes to read the track.

• Seek Time – Seek Time is measured by the average time it takes for the mechanical arm to move between different Tracks on a hard drive. This is important in the instance where data is scattered between different tracks on a hard disk. The faster the mechanical arm can move between the tracks, the faster the data can be accessed for use.

• Interface Type – The Interface Type was once thought to be the biggest “speed” issue with hard disk drives. Since the interfaces were so slow, (UATA/133 was only at 133mbps), the theoretical speed was significantly limited to the interface type. However, with the introduction of Serial ATA, the theoretical transfer rates are increased to over 10.0 gb/s which currently ( 2008 ) is not touched by modern hard disk drives.

There are three primary connecting interfaces on modern hard drives which include IDE/ATA, Serial ATA, and SCSI.

*Note: SCSI interfaces come with over 11 variations so I chose to leave the images out to reduce “information overload”.

IDE/ATA Connections	Transfer Speed
ATA/66	66 mb /s
ATA/100	100 mb /s
ATA/133	133 mb /s
SCSI Connections	Transfer Speed
SCSI FAST	10 mb /s
SCSI FAST – 20 (Ultra)	20 mb /s
SCSI FAST – 40	40 mb /s
SCSI FAST – 80	80 mb /s
SCSI FAST – 80 (wide)	160 mb /s
SCSI ULTRA320	320 mb /s
SATA Connections	Transfer Speed
SATA/150 (SATA rev 1)	1500 mb /s
SATA/300 (SATA rev 2)	3000 mb /s
SATA/IO (SATA rev 3)	6000 mb /s

• Access Time – The Access Time is a combined metric. Access Time is determined by the Interface Type, Rotational Latency, and RPM of a hard disk drive. This is why critics are so concerned about the Access Time of the Hard Drives. It provides the best rounded number for measuring the hard drive performance. Hardware manufacturers like to measure in Seek Time as its a mechanical measurement much like horsepower is to automotive.

What else can affect the “Speed” of a hard disk?

When modern hard disk manufacturers determined that the hard disk is the slowest part of a computer, they started to integrate Read/Write Caches on the hard disk itself. A Read/Write Cache is designed to allow small amounts of data to be stored in memory to be written to the disk when the hard drive is busy performing other tasks. This significantly improved system performance as the CPU doesn’t have to wait on the write operation to complete prior to completing other processes.

Well there is an issue with this… Since the hard drive is powered from the power supply, if the power fails or a power surge occurs, any data that is stored in the read/write cache is gone. That is why currently the industry is not releasing hard drives with 1GB of write cache. The loss of 1 GB is significant to the stability of a system (and your sanity). New motherboard manufacturers are now providing the ability to integrate a Battery Backed Cache on the motherboard to be able to store the write cache. This not only significantly improves the speed of the system, but even in the event of a power failure, the data is safe for 72+ hours. This is similar to what GOOD RAID controllers (discussed in a different article) do.

I always like to use the “compiling a program in Visual Studio example” when explaining BBC because compiling code is a very hard disk intensive operation. (Please keep in mind this example is a very high level look at what a write cache does.)

There are three core operations that occur when compiling code:

1. Reading the lines of code line by line
2. Processing those lines of code and outputting their results
3. Writing the results back to the hard disk

In systems without battery backed cache, the hard drive will read a line of code, process the line, write the line to the hard drive, then “rinse and repeat”. This causes the hard drive to STOP reading from the current sector, jump to a different track, then write to that track, then when needing to process the next line of code, jump back to the original track. This creates a situation called Disk Thrashing where the disk reads and writes from two different physical locations.

With the write cache, the computer has the ability to perform all three of the operations simultaneously while compiling code.

1. Compiling code

• Reading the Lines of code line by line
• Processing those lines of code and outputting their results
• Writing the results to the battery backed write cache

2. Writing the Write Cache to the hard disk.

Your system no longer has to wait for the hard drive to complete a write to the disk prior to reading more information from the hard disk. There is more complexity to the write cache operations but to save your sanity, I’ve chosen to leave them out.

Circling back to Disk Trashing for a second… Its Important!

Disk Thrashing actually occurs more frequently than most people think. In fact, as long as you have a page file on your computer, you will ALWAYS have Disk Thrashing. Why? When a page file is enabled on a computer, the memory operations are stored in a file on the root of c:\ named pagefile.sys. As shown in the image above, when utilizing a program which uses a lot of memory, the the head has to move between the pagefile.sys and code.vb file.

This causes an issue called Disk Trashing. The head actually thrashes between the two tracks on the same platter. This is what makes that clicking or “thinking” noise in your hard drive. Recalling Seek Time / Access Time, you will know that when using multiple files, the head has to seek between the different sectors on the different tracks. Everytime it seeks to a new track, it takes X number of ms to get to each sector which means you have to wait X number of ms between accessing multiple files.

This significantly reduces the performance of the computer and ultimately reduces the longevity of the hard disk. The mechanical drive for moving the mechanical arm on the hard drive can fail when excessive disk thrashing occurs over multiple years.

NOTE: Please note that this is NOT a reason to disable your page file. A page file is required in systems which frequently run out of RAM. Also this issue may not occur if the page file is on a different platter than the data being accessed. This also is not true if the page file is stored on a different physical drive than the drive being accessed.

Brent – I don’t care about all of this stuff – What should I chose as my hard drive???!!!

I always try to stay away from Manufacturer specific choices as opinions are like eyes, everyone has more than one. So, objectively I’ve come up with the following metric to help you in your path to hard drive heaven.

(((1-(RPM/60000)) * Seek Time) / Buffer Size in MB) * (Drive Size in MB/Interface Speed in MB/s) = Lowest Number is Best Drive

So real world how does this look?

Home User Devices

Barracuda® 7200.10 Hard Drive

Western Digital Caviar Green WD10000CSRTL

Maxtor Basics™ SATA II/300 Hard Drive Kit

Enterprise Devices

Western Digital VelociRaptor

Seagate Savvio 15k

Cheetah® 15K.5 Fibre Channel