From Guru to Guide

Guides are what I have always written, first in forum threads and now on this site. Over the years the forum threads, a boot-time guide, and the test sections in my reviews turned into Flash Foundations, SSD Benchmarking 101, and a set of tools you can run yourself. I write my own code to take measurements, and I build tools so you can run a test yourself instead of reading a description of it. My other essays are on the blog, and the software page lists the tools.

Guides were always the point

I started out answering questions in forum threads. My Windows install and optimization guides on Overclock.net were long lists of steps, and people worked through them on their own machines and asked questions in the thread when they got stuck. At The SSD Review I wrote a guide on cutting boot times, and my Tom’s Hardware reviews each included a section explaining how the drive was tested.

A guide has always been the easiest way to make my testing useful to someone else, so I kept doing it here. Flash Foundations is a ten-part series on how NAND flash and SSDs work, from the physics of the cell to the controller and firmware. SSD Benchmarking 101 covers how to test a drive without fooling yourself. How I Made SSD Validation Repeatable describes the process I built for validation work.

Then tools

The other change is that I now build tools as well as guides. A test you can run yourself teaches more than a description of it. The software page lists what I have released so far: a hardware stress and telemetry tool called PS-FU, terminal tools such as dtemp and FindIO, Windows utilities including IOSpeX and TriageIO, and browser tools that show how NAND cells drift, how a flash translation layer and garbage collection behave, and whether TRIM is on.

The goal is the same as it was in those forum threads: explain what the hardware actually does, show how to check it, and let people repeat it for themselves.

Code as instrumentation

My testing used to center on endurance workloads and close study of power traces. Now it depends on scripting and automation in Python, C++, and Perl, and the code has taken the place of my thermal chambers. Data is only as good as the script that extracts it.

Instead of relying on vendor tools, I build my own. My frameworks are designed to mimic how systems behave in the wild, with memory under pressure, workloads shifting in real time, and controllers making split-second tradeoffs. The scripts show when a system is balanced, when it is bending, and when it is about to break. Turning raw data into patterns and cause and effect lets me show why a technology performs the way it does.