Explained · four
Five columns appear across most of our tables. Here is what each one measures, why it is worth publishing, and roughly what a good or bad value looks like on a machine you actually own.
The headline
The clock starts when the job is added and stops when the finished payload exists on disk, verified and extracted. Not when the download completes, and not when the client says it is done.
This is the only number that corresponds to something you experience. A client can finish downloading quickly and then spend a minute checking and unpacking, and from where you are sitting that minute is part of the wait. Measuring the download alone would flatter clients that do their work afterwards, which is most of them.
It is also why our architecture looks unusual in these tables. We verify each piece as it arrives and unpack while the download is still running, so when the last article lands there is very little left to do. Other clients stage the whole post to disk, then verify it, then unpack it, as three phases in sequence. On an easy job the difference is modest. On a large or damaged one it is most of the result.
The one people misread
The largest amount of memory the program held at any moment during the job. RSS stands for resident set size, which is simply the memory actually in RAM rather than promised or reserved.
Higher is not automatically worse, and lower is not automatically better. Memory is being spent to avoid doing something more expensive, usually reading the same data from disk twice. The question worth asking is whether the spending buys anything and whether it is bounded.
Bounded is the important word. A client whose memory grows with the size of the job will eventually meet a job it cannot finish on your machine, and the failure arrives as swapping or a killed process rather than a polite message. We hold a budget and stay inside it, which is why we can put a 190 GB job through a machine with about 1.1 GB of memory available to us. A figure like 9.3 GB on a 190 GB job is not merely large, it is a different shape: it scales with the work.
Where our own memory rises, we try to say what it bought. On heavily damaged posts the current build holds parity data in memory in order to repair immediately rather than fetch more later, which takes peak memory from about 0.8 GB to about 1.3 GB and saves about ten seconds. On an undamaged post that spending does not happen and the figure is 0.24 GB.
The energy proxy
The total processor time consumed across the whole program, added up across every core. It is a measure of work done rather than time elapsed, so it can be much larger than the clock.
If a job takes 100 seconds and reports 1,600 processor seconds, roughly sixteen cores were busy for the whole run. That matters for three practical reasons: it is heat, it is electricity, and on a machine doing anything else at the same time it is contention. A client that finishes in a reasonable time while saturating every core has not been efficient, it has been expensive.
This column is where the widest differences on the whole site appear, wider than any finish time. For byte-identical output on the same damaged post, we have measured a thirtyfold spread in processor seconds between clients. It is worth checking before you assume two clients that finish within a few seconds of each other are doing comparable amounts of work.
The two disk columns
Peak disk is the most extra space the job needed at any one moment. Volume I/O is the total amount of data read and written to get there. They answer different questions.
Peak disk is a hard constraint. It decides whether the job can run at all. Most clients write the complete post to disk and then unpack a second copy alongside it, so they need roughly twice the payload in free space. For a 190 GB job that is about 313 GB free before you start, against about 157 GB for us, because we unpack while downloading and never materialise the archive volumes. If your disk cannot hold twice the job, that difference is not a percentage, it is whether the download happens.
Volume I/O is wear and time. Writing the post, reading it back to verify, reading it again to unpack and writing the output is four passes over the data. Doing it in one pass is roughly a third of the traffic, which on a solid-state disk is drive lifetime, and on a slower disk is often the actual bottleneck rather than the network.
A note on how we read these two, because it caught us out and might catch you out reading our tables. Both figures come from counters that cover the whole disk, not a single program. That makes them an excellent check on whether a benchmark was contaminated by something else running, and it means a number that looks impossible usually is: a 6.5 GB job reporting 144 GB of disk traffic is not a client behaving strangely, it is two jobs sharing a machine.
Reading a table
The tables themselves, with the build and date beside each one, are on the benchmarks page, including the legs we lose.