Stress Testing Windows mini PCs with OCCT Overclock Checking Tool

Orange Pi Development Boards

I’m mostly a Linux user, but the marketplace has chosen Windows 10 as its preferred operating systems for mini PCs, so I’ve been reviewing fanless (or not) mini PCs running Windows 10 for around two years since Intel decided to provide low cost and low power processors. I normally run some benchmarks such as PCMark 8 or 3DMark, as well as typical user tasks, while monitoring CPU temperature and throttling using HWInfo64 utility, but those benchmarks are not really pushing the device to its limits. However, I’ve just learned out about OCCT “Overclock Checking Tool” that’s just doing that, and installed OCCT 4.4.2 on Vorke V1 to check it out.

Click to Enlarge
Click to Enlarge

The tool has four taps: CPU: OCCT, CPU: Linpack, GPU: 3D, and Power Supply to stress test different part of the system. I just let it run for over 3 hours after pressing the ON buttons, and you can see all four cores of the Braswell processor at 100% CPU usage in turbo mode, the memory used, cores frequency, and CPU cores temperature in real-time.

Click to Enlarge
Click to Enlarge

I also ran HWInfo64 at the same time to double check CPU temperature and throttling, but it turns out OCCT is also generating charts for CPU usage, bus frequency, CPU #0 frequency, memory usage, and temperature for all cores. You can access the charts by clicking on the icon in the right of “Monitoring” on the right part of the screen (first screenshot). I’ve included one of the charts showing CPU usage and temperature.

Click to Enlarge
Click to Enlarge

This shows Vorke V1 appears to be handling high loads very well, and does not overheat. It’s not a fanless system though, so the included fan certainly helps.

OCCT is free for personal use, and costs $150 per year for commercial use, with the commercial version also supporting custom tests, CSV output, and other features.

5
Leave a Reply

avatar
5 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
rasz_pltkaiser Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
tkaiser
Guest
tkaiser

Am I’m missing something? But the graph only contains temperature and CPU utilization (100% can be achieved with both pretty lightweight stuff and heavy workloads) so the most important parameter — CPU clockspeed / throttling — is missing?

These small Intels use the same wide cpufreq range as more recent ARM boards so without knowing actual CPU clockspeed a look at ‘CPU utilization’ is pretty useless: If throttling allows jumping between eg. 500 and 2000 MHz then a system running with 100% CPU utilization at 500 MHz is less busy than showing 26% while running at 2000 MHz.

At least with CPUs/SoCs/systems that implement DVFS (dynamic voltage frequency scaling — adjusting the voltage the CPU cores are fed with depending on clockspeed) it can be worth a look whether the cpufreq governor works as expected since keeping SoC/CPU at lower clockspeeds utilizing more cores (and getting close to ‘100% utilization’) means feeding SoC/CPU with less VDD_CPUX voltage resulting in less consumption and temperatures. On the other hand the ‘race to idle’ concept allows SoC/CPU to enter deep sleep states more early/often when maximum clockspeed is allowed so it depends on the workload in question.

But at least without monitoring actual CPU clockspeeds I find it really hard to draw any conclusions 🙂

rasz_pl
Guest
rasz_pl

tkaiser second screenshot (hwinfo64) has info you want, it keeps track of any throttling, this screenie shows no throttling during the test

tkaiser
Guest
tkaiser

@cnxsoft
I was more talking about the usefulness of such graphs in general. If it’s known that cpufreq can switch between 480 and +2000 MHz then leaving it out is always wrong (the aforementioned example of a fan equipped device being no exception — 100% CPU utilization means nothing).

Many users (even experienced ones or ‘benchmarkers for a living’) still don’t get the idea and work with useless tools like Ubuntu’s System Monitor relying on CPU utilization graphs that are 100 percent meaningless on devices that implement cpufreq scaling. We should educate users to not fool themselves all the times 🙂

Regarding cpuminer: I also use the 32-bit armhf version to test efficiency of throttling/dvfs settings on ARM devices since monitoring the khash/s rate together with other values is convenient (either ARMv7 or ARMv8 — the 32-bit version contains some optimized assembly code that would be dropped when compiling for ARMv8). It does a way better job heating up CPUs/SoCs than stuff like ‘cat /dev/zero /dev/null’ (that will show 100% CPU utilization when run on all cores but is laughably lightweight). But on ARM it will be even outperformed by cpuburn 🙂