I like stress-ng, due to the diversity of different methods it has. Hardkernel used the following, in their thermal testing of the N2:
Agreed, it's one giant chest filled with benchmarking tools, something for nearly everyone.
What's a little harder to tell (without looking deeper than I've done so far) is how deeply it can go into modern ISA extensions, which a) allow incredible speedups for some use cases b) often need to be hard-coded in assembly, because compilers can't handle them.
But then I'm far from using these SBC for the supercomputing workloads I run on the bigger stuff in the lab, so it's perfectly ok to just run generic stuff.
I haven't tried compiling prime95 on AARCH64, while I know it's got plenty of hand-crafted assembly code for x86. That I like it mostly for the ability to test the memory subsystem as well and catch instabilities that ordinary benchmarks wouldn't expose.
For a more real-world workload, I find that povray is an easy option.
Anything visual has the advantage of potentially catching invalid data, which in my case is much worse than crashes.
Where do your source heat sinks? I've found it difficult to locate good quality copper heatsinks of any substantial size. For my Gemini Lake, I found a guy selling some ancient server heatsinks on ebay that fit with a custom hold-down I rigged. But, I've generally been disappointed with the selection of heatsinks I could find either on ebay or even some electronics component suppliers.
For the four passive N5005 Atoms, they came with a heatsink installed. I just made sure the chassis had enough airflow, too. But they are mostly from a generation of Atoms that still stuck with the 10 Watt max TDP.
My Jasper Lake is a NUC and as such comes with a fan. But I play with PL1/PL2 and TAU on my six NUCs to ensure they never bother.
For the RP5 and OP5 I just take a few of what's offered on Amazon and test them: all of them are too cheap to be worth returning.
I was a bit worried about heat initially, but as far as I can tell the RP5 just won't throttle with the €12 passive case and the OP5 throttles very nicely with a pretty small passive aluminum heatsink that's barely bigger than the SoC itsself and about 20mm in height, so it will just fit in the case.
Under constant max load that has it go from 2.252 to 2.1 GHz while staying near 80°C, which I consider perfectly ok. Throttling used to be terrible, a screeching halt, a dysfunctional system or nearly so.
Today variable peak clocks are perfectly normal for whatever reason and overheating SoCs behave very gracefully, to the point where the OP5+ runs fine (albeit slowly) even without a heat sink. So it's mostly about pushing cooling to the point where it's 'good enough' for the SBC's use case.
If the Alder-N board I end up getting has enough space, I might try one of the server heatsinks with a vapor chamber.
Copper and vapor chambers are for stuff that burns 200-400 Watts and I guess it's fluid cooling after that.
The first 24x7 system I was concerned about in terms of noise was my firewall: when the passive Atoms were overwhelmed with the fat packet inspection ruleset I ran on my pfSense on my Gbit uplink, I got an i7-7700T, a 35 Wattt Kaby Lake on a Mini-ITX board with 6 Intel Gbit NICs that would only fit a low-profile Noctua NH-L9i into the chassis. That fan is relatively weak while the heat-sink is astonishingly massive and it turned out a perfect combination that remains inaudible 1m away in a direct visual line. It only needs cleaning every couple of years: dust stopping fans is the main cost of active cooling, and mostly a problem if you just happen to be away when Murphy strikes...
Today it's clearly a candidate for replacement with an i3-N305 offering 2.5Gbit links (should I decide to upgrade the broadband), but so far it's been doing just fine for nearly 8 years.
Even the N305 should stay below that i7-7700T in terms of cooling requirements, while fully passive cooling beyond 15 Watts has near exponential heatsink size implications and just hits a wall before three digit Wattage no matter what.
I got some SK Hynix P31 Gold M.2 drives to use on SBCs, due to their excellent power efficiency. However, I take your point that the real issue might not be the amount of heat generated by the drive, but rather how much it picks up from the CPU.
NVMe for an SBC seemed excessive for a long time, but the only option cheaper today is used hardware: I'm happy to have some use for sticks that are still perfectly good but much harder to recycle than SATA-SSDs, which I can put into JBODs very cheaply and easily.
Those Samsung sticks still reported 100% spare capacity when I relegated them to 2nd rank after 4TB PCIe v4 sticks pushed them out of the workstations mostly for capacity reasons. But I like taking care of my stuff and not burn it for fun, while storage is for safe-keeping, after all.
I lack experience with just how badly NVMe sticks will deteriorate under heat, but I don't get paid to find out either. So I try to make sure they stay below 60°C under normal operations. If that requires some glued-on heat sink, I'd slightly prefer that over active cooling, but I don't mind what I don't hear.
True. I would tend to use power limits to avoid throttling, however.
They are very nearly the same these days, just a different input to trigger the same action and no longer a survival mechanism that crashes the system. I use the power limits to limit the noise and don't worry about the temperature, at least on the SoC. True, there are measurable differences in longevity which my former colleagues at Bull loved to tell me about, but those are measurable in HPC systems with tens of thousands of active components, kept running as near to peak 24x7 as possible.
taskset is what I use on the Alder Lake i9 that I use at work. I forget if I've tried it on the ODROID N2...
I bought Project Lasso only to be told that I should use the free taskset... but I found both rather more confusing than helpful. Since 'work' is always on Linux and cpuctl comes included there, I've given up on managing E vs. P on Windows, especially since I then use 'perf' to measure the results.
Sadly the ARM SoCs are missing the sensors and counters 'perf' uses on x86 s and even the instrumentation for 'perf' on AMD seems to be quite below the level of detail the hardware supports: Intel hardware only measures a summary value for the P and the E core clusters, not for every individual core, which AMD seems able to do, as per HWinfo (Windows), but won't on Linux evidently because it requires an NDA.
That's not great info, since only part of it could be accelerated, or perhaps they're using the GPU's shader array instead of its hardware codec engine.
There is simply no VP9 or AV1 codec support on the Raspberries and without a dedicated IP block those formats are just a no-go on <10 Watt hardware, especially at today's resolutions. Most streaming services will just adapt and transform their content on the fly using their fantastic dedicated video transcoding hardware, so if Raspberries only support X.265 that should be fine for years to come.
But if you're trying to consolidate your own material on the most modern and compact codec available, you'd have to look elsewhere.
Why would they need to maintain backward compatibility? You know there are different drivers for the VideoCore IV and VI, right? The GPU in Pi 1 to 3 is handled in the vc4 driver, while Pi 4 and 5's GPU is handled in the v3d driver.
That's from what they said in interviews. But it's also from what I know about the market.
First of all, GPU architectures don't come for free. Not only are they costly to develop in hardware and software, they are also a minefield full of somebody else's patents. And those elephants are very unforgiving in defending what they consider their home turf. One of the main reasons why GPU drivers so often weren't made available in source was that it would give the opposition so much more clues about technical solutions both had developed pretty much independently, while only one could win the patent battle. You could come up with a brilliant clean-room design for a new GPU architecture today, yet hundreds of lawyers would shut you down before you'd ever get a test chip from a fab.
It's an area where China doesn't care in its quest for AI sovereignty if not supremeacy, but is still careful not to sell their home-grown GPUs outside either, because that's when they'd get shot down. ARM is using AMD/ATI technology and patents and between team red and green, only team blue has enough money to afford a patent firewall and teams big enough to do both, hardware and software GPU design.
For the Raspberry PI foundation the cost of doing something fundamentally new, would have been prohibitive, while the cost of using a vendor off-the-shelve GPU ip block like Mali, could have easily doubled the licensing cost... for the GPU alone, not including the media codec blocks.
I understand that the RP VPU evolution is a Broadcom/RP co-design using a technical base that is safely different enough from what the big guys are doing, but should they try to come close to their turf, they'd have to pay up big, one way or another.
While I don't overclock x86, I have started fiddling with power limits, after discovering that you can raise them even on non-K Intel CPUs. I now run my "65 W" work PC at a limit (i.e. PL1) of 80 W, which its thermal solution can keep below throttling temperatures in the air conditioned room where it resides. This not only gives me better performance after Tau expires, but also gives me a longer Tau (i.e. boost window). I haven't had to change PL2, since I've never seen it reach the stock limit of 202 W.
Same here, except that I [very nearly] only care about the noise and consider temperature as just another input that slows the clocks. While the NUCs will set some boundaries, they are typically way to high for my noise tolerance so I play with TAU and PL1 to keep things at bay, while PL2 typically stays far beyond what you'd expect from a -U class SoC.
On an Erying that uses an -H class SoC on a mini-ITX mainboard for what is essentially a desktop, I've actually raised PL2 to 120 Watts and PL1 to 90, after carefully tuning the cooling and replacing the vendor's filling material on the naked die with liquid metal: it's my fastest Alder-Lake by far.
This one seems pretty good, but I haven't tried to independently verify what it's reporting:
Thanks, but that won't fit into my 230V mains, I'm afraid... we don't run 'sad faced' power sockets here
This used to be above the point where Intel CPUs would throttle... I don't love the idea of such high temps. I normally like to keep die temps below 80 C.
IIRC, my Pi v3 I think would would start to soft-throttle around 80 C, but I've seen it go as high as 83 or 84 C.
I'm under the impression you still think of throttling as a self-destruct protection mechanism, while these days we have SoCs transplanted from laptops to desktop throttling just because they are afraid to be 'unfomfortably hot' to human skin (AMD 8700G teething issue).
Throttling is really just a lowering of the top clocks to fit an operational envelope, that include temperature as one of many meters, which also happens to be related to Wattage.
And while it's obviously a waste of money to buy a 3 GHz chip that only ever runs at 800MHz without cooling, I'm no longer worrying about a system that drops to 90% of top clocks, if it's being hit by a power virus or some runaway workload that is extremely atypical.
Smartphones are engineered to minimize idle power, though. They really try very hard, since idle power consumption is inversely-proportional to battery life.
Sure, but while most of my systems aren't running on a battery, they run on €0.3/kW/h, so I'd like even my cheap systems to go easy on the juice, especially since they aren't heavily used. But since they run typically in a high-availability cluster, shutting them down isn't really an option, either. It's one reason I'm interested in these mixed low- and high-power cores and having 7 out of 8 sleeping when there is nothing going on.
Facebook
Twitter
Instagram