Peak speed and useful speed are not the same
GPU search tools often print a throughput figure in MKey/s or GKey/s. That number is easy to compare, but a single sample can be misleading. Kernel compilation, device initialization, thermal ramp, clock boosting and concurrent desktop load all affect the first part of a run.
For distributed scheduling the useful question is not “what was the highest number displayed?” but “what speed can this device sustain long enough to finish the kind of assignment it will actually receive?” OpenPuzzle uses benchmark performance for work sizing and compatibility, not for giving faster participants preferential access to the search space.
Warm-up changes what you are measuring
OpenCL devices may spend noticeable time compiling kernels before steady execution begins. CUDA startup behavior is different, and CPU engines have their own initialization costs. A very short benchmark can therefore measure setup overhead more than search throughput.
A practical benchmark should allow the backend to initialize, observe several throughput samples and use a representative sustained value. If the speed keeps falling as the GPU heats up, the lower sustained figure is more useful for planning than the initial boost result.
Backend choice matters
The same machine can expose different execution paths. NVIDIA hardware commonly uses CUDA with cuBitCrack, while OpenCL allows other supported devices to participate. CPU execution through KeyHunt is much slower for the same brute-force workload but remains useful for compatibility testing and for machines without a suitable GPU.
Comparing results only makes sense when the puzzle mode, keyspace behavior, engine settings and runtime conditions are comparable. A number from a different algorithm or search mode should not be placed in the same table merely because both are reported in keys per second.
Thermals and power are part of the benchmark
A device that starts fast and throttles after ten minutes will finish a one-hour assignment closer to its throttled speed. Fan profile, case airflow, power limit and other GPUs in the same system can all change sustained performance. This is especially relevant in mixed-GPU machines where one card may increase the thermal load experienced by another.
For that reason OpenPuzzle treats measured performance as operational data that can be refreshed rather than as a permanent ranking attached to a client identity.
Why speed should size work, not privilege users
If every participant receives the same key count, a slow CPU may hold an assignment far longer than a fast GPU. If faster devices receive exclusive priority, the project stops being an equal-access coordinator. The useful compromise is to use speed to estimate an assignment size that fits the target runtime while keeping assignment selection independent of participant reputation or hardware prestige.