Surface Pro 11 stayed at 61.6% after five minutes of full load

Even under full load for 301.0 seconds on a Surface Pro 11th Edition, % Processor Performance stayed around 60.2% for the first five samples and 61.6% for the last five.

The result was completely unexpected. With a fanless Snapdragon X Elite X1E80100, I expected the clock to fall after using all cores for about five minutes. Instead, the end was slightly higher. The maximum was 69.5% and the minimum 55.5%; across all 48 samples there was no line that sank as time passed. My “it must fall” assumption was wrong. I could not read temperature directly, so I do not have enough evidence to say there was thermal headroom, but at least from the clock counters it did not fall.

What stood out almost as much as the lack of a decline was that the entire interval stayed around 60%. The nominal clock is 3.40GHz, but the observed Processor Frequency ranged from 990MHz to 2397MHz, with a mean of 1512.9MHz. Under simultaneous load on all cores, the steady operating point appears to be set around here before any thermal drop occurs. Short single-threaded boost behavior may have been a different question from the start.

The measurement was on July 26, 2026, with AC power connected and the default Balanced power plan. I did not move far from my normal state. The environment was Windows 11 Pro 10.0.26200 ARM64, with native ARM64 Python 3.12.10.

How the load and monitoring ran

I generated the load with Python's ProcessPoolExecutor. It created 12 processes, each running a simple integer-arithmetic loop. I did not target the GPU or disk; I just made the CPU busy. That simplicity is a weakness, but it is reasonably close to the small conversion jobs I usually run.

from concurrent.futures import ProcessPoolExecutor
import time

def burn(until):
    x = 0
    while time.perf_counter() < until:
        x = (x * 1664525 + 1013904223) & 0xffffffff
    return x

until = time.perf_counter() + 300
with ProcessPoolExecutor(max_workers=12) as pool:
    list(pool.map(burn, [until] * 12))

Monitoring ran in a separate PowerShell process. Every five seconds it read \Processor Information(_Total)\% Processor Performance, \Processor Information(_Total)\Processor Frequency, and \Processor(_Total)\% Processor Time.

while ((Get-Date) -lt $end) {
    $perf = (Get-Counter '\Processor Information(_Total)\% Processor Performance').CounterSamples.CookedValue
    $freq = (Get-Counter '\Processor Information(_Total)\Processor Frequency').CounterSamples.CookedValue
    $busy = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue
    [pscustomobject]@{
        t = Get-Date -Format 'HH:mm:ss'
        perf = [math]::Round($perf, 1)
        freq = [math]::Round($freq, 0)
        busy = [math]::Round($busy, 1)
    }
    Start-Sleep -Seconds 5
}

This setup has weaknesses. The monitoring PowerShell process also uses CPU, and it calls Get-Counter three times, so it is not an observer with zero load. The observer changes the scene a little. It is rough for a strict benchmark, but close to my use case of watching the machine while ordinary automation is running.

The actual load lasted 301.0 seconds, 1.0 second longer than the 300-second target. Waiting for ProcessPoolExecutor to finish and the monitor's timing contribute to this amount of drift.

Counters captured along the way

Showing all 48 records would make the table too long, so I include the first five, middle five, and last five exactly as recorded. % Processor Performance and % Processor Time are percentages; Processor Frequency is MHz.

% Processor Time reached 100.0% at most, with four samples at 100.0%. There were also nine samples above 90%. The mean across all samples was 71.3%, so the table does not look permanently pinned, even though the load itself kept 12 processes running. Reading Windows counters from another process likely makes the sampling window and monitor timing visible in this way.

I had assumed busy would always be close to 100%. The measured range was 33.5% to 100.0%, which was confusing at first. The load had not necessarily disappeared; the monitoring method was coarse. I expected too clean a line while running both the burn and observation on the same Windows system.

Did the clock fall?

The question was whether % Processor Performance declined over time. The first five averaged 60.2% and the last five 61.6%, a difference of 1.4 percentage points, not a decline. The overall average was 61.7%.

The maximum, 69.5%, appeared near the end at 20:42:44. If thermal stress had caused strong throttling late in the run, that value would be unlikely to appear in the last five samples. Of course, 48 samples at five-second intervals could miss a short dip. Even so, this observation did not show a five-minute continuous load producing a downward trend.

On the other hand, Processor Frequency reached only 2397MHz against the nominal 3.40GHz. The minimum was 990MHz. The mean of 1512.9MHz looks low by itself. Combined with % Processor Performance being stable around 60%, however, it reads more like a deliberately modest sustained clock when all 12 cores are active than thermal throttling.

Short single-threaded work should look different. This result applies only to running 12 processes at the same time.

What I could not measure

There were failures too. I wanted CPU temperature, but I could not obtain it from the PowerShell environment on this machine.

Get-StorageReliabilityCounter can report SSD temperature. It did not reach the CPU temperature sensor on the Surface Pro 11th Edition in the same way. I had intended to use only standard Windows counters and got stuck there.

Therefore, I do not have enough evidence to say the machine had thermal headroom. The measured statement stops at “no clock decline was visible over five minutes.” This log cannot tell whether the chassis temperature rose, whether there was spare headroom, or whether another control held the clock down first.

The other limitation is duration. I targeted 300 seconds and measured 301.0 seconds. Ten or twenty minutes could produce a different result. On a fanless machine, the long steady load is more interesting than a short burst; this was only a five-minute first look.

My interpretation of the workload has changed

I had assumed that a fanless machine would quickly struggle with any long-running task. That view did not hold for these five minutes. The Surface Pro 11th Edition stayed quiet and, at least in % Processor Performance, remained around 60%.

It would also be wrong to be too optimistic. Seeing 3.40GHz does not mean all 12 cores will run near that value. On this machine, the measured all-core frequency ranged from 990MHz to 2397MHz. It feels less like a machine that sustains maximum performance and more like one that starts at the level it can sustain within a fanless thermal envelope.

After seeing this result, I have less reason to avoid short batch jobs. A Python conversion or aggregation lasting a few minutes is unlikely to suddenly collapse in the middle. A workload lasting 20 minutes or more, such as video encoding, still needs a separate test.

The conclusion as of 2026-07-26 is that “fanless means performance cannot be sustained” was not supported by this five-minute test. Temperature was not measured and the duration was short. Next I want to find a way to read CPU temperature and repeat the same table for more than 10 minutes.