The machine that halved its own speed, and what it taught me about enclosures
Thermal throttling read as a mechanical design failure.
A machine that quietly halves its own working speed under load is very often not malfunctioning at all, it is a processor or motor controller deliberately doing less work to cut its own heat generation before an internal temperature limit is reached, and treating that slowdown as a software fault instead of a symptom of a cramped enclosure wastes far more time than the slowdown itself ever costs.
A control loop trading speed for survival
Most modern processors and motor controllers carry a built-in temperature sensor watching their own die or winding temperature, wired into logic whose only job is protecting the component from heat-driven failure: atoms migrating through fine conductors, insulation breaking down, windings losing their varnish. Once the measured temperature nears a safety threshold, that logic reduces a processor's clock speed or a motor's duty cycle, cutting the electrical work being done and the heat that comes with it. The threshold is set with a margin below the temperature where real damage would begin, so the protection shows up as an inconvenient slowdown long before anything is at risk. A machine behaving this way is reporting, in the only language it has, that its case cannot get rid of heat as fast as the component is producing it.
A dog that slows down on a hot day
A dog running hard on a hot day pants harder as its body heats up, since panting, moving air quickly across the moist surfaces of its mouth and throat, is its main way of shedding heat when sweating barely works through fur. If it still cannot shed heat fast enough, its body slows it down and eventually stops it running altogether. Nobody watching this concludes the dog has a broken leg, because the behaviour so obviously fits a heat problem. A processor or motor controller throttling itself is doing the same thing for the same reason, and the fix in both cases is to get more heat out of the surroundings, where pushing the runner harder would only make things worse.
Full speed, half speed, and back again
Throttling rarely arrives as a single step down. A component runs at full speed until it crosses the threshold, drops sharply, cools as the enclosure catches up, climbs back toward full speed, and hits the threshold again a short while later. If it spends roughly equal time at full speed and at a much lower one, averaged over a few minutes the result looks exactly like a steady halving of throughput. A machine alternating every ten seconds between full speed and a crawl delivers little more than half its rated work each minute, and a progress bar or job timer, averaging over the whole run, shows only the smooth, disappointing result and none of the sawtooth underneath it. Spotting the oscillation under that average points straight at a heat balance problem, heat being generated faster than the enclosure removes it, and away from any fixed ceiling in the hardware.
Check the heat before the software
Once a slowdown under load is read as a heat symptom, the diagnosis changes order. The temperature of the case, the airflow reaching the hottest component, and whether heat has any real path out of the enclosure all come before reinstalling software or replacing a part suspected of wearing out. A machine throttling under a workload it handled comfortably a year earlier, with no change to the software or the task, is describing an enclosure that has become worse at shedding heat, through a clogging vent, a fan slowing as its bearing wears, or dust across a heatsink's fins. Fixing the airflow restores the original speed permanently, while no software change can, since the throttling logic reasserts itself under load however the code around it is rearranged. The heat check costs almost nothing, a hand held near the case, a look at whether a fan is still spinning, a glance at whatever temperature reading the machine exposes, while chasing the wrong cause first can burn hours or days.
My key error with this
When the vehicle came in slower than expected I assumed something mechanical was wrong with the thrusters, since a machine that will not reach the speed it should is exactly what a fouled bearing or a damaged blade produces, and I spent a while looking for a fault that was not there. Testing them properly, in the actual installation rather than against the figures they were quoted at, showed the thrusters were behaving correctly and that the expectation was the thing that was wrong, because the numbers I had built the plan on came from conditions the vehicle never operated in. Once the expected performance was reset to what the test actually measured, the vehicle did its work comfortably and had done so all along. What replaced the belief is that a shortfall against a prediction is as likely to be a fault in the prediction as a fault in the hardware, and that measuring the thing in place is the fastest way to find out which.