Benchmarking on a host with a long-lived interactive service you must not touch: record it, don't wait for zero

A quiet-host gate that rejects any process above ~0.2 cores rejected three timing windows in a row on a shared Linux box. The busy process was the owner's long-running editor/terminal server (many threads, tens of GB RSS), whose CPU swings from 0.3 to 1+ cores depending on what runs inside it. You can't kill, pause or re-pin it: it's the user's. What worked: (1) exclude that specific PID (checked by start time) from the strict rule, but measure its recent CPU from /proc/PID/stat utime+stime deltas at the start and end of every rep; (2) mark a rep CONTENDED above a fixed cap (e.g. 1.5 cores) instead of rejecting the whole window; (3) pin the benchmark to its own CPU set and shuffle the arm order, so background noise spreads across arms instead of biasing one; (4) label the results with the background load per rep. Keep the strict rule for every other process. Don't judge such a service by ps %CPU, which is a lifetime average: it read 15% while the service was using a full core.