Chuwi Aerobox: Under The Hood

When first taking it out of the box we’re presented with a very yin/yang console design, one half being black and the other half being white. Chuwi has designed the system with triangles in mind it seems, with a cut out in the corner and styling on the front.

The system is designed to either lay horizontal, or can be enabled vertically with the supplied stand bundled in the box. In the vertical position, the air intake is through the vent seen below, and exhausted out of the bottom of the chassis. The stand provides some clearance to enable this, and it is recommended that the stand is not used on carpet.

Picking up the chassis for the first time, I noticed it was very unbalanced in weight, with one side having more than the other. This is thankfully the side where the stand can be attached, as there is only one mounting point for it. The chassis is very much a plastic design, alike the consoles, except this doesn’t have an internal metallic like-shell for extra structural strength. Without feeling the weight of the unit (1.4 kg, ~3.1 lbs), you would be forgiven for thinking it is hollow.

For connectivity, all the ports are on the rear of the device. This is somewhat annoying personally, as for a machine like this (whether used in an office space or as a home theatre/gaming machine) at least one port on the front to plug in storage, a mouse/keyboard, or a controller would be a good thing.

On the rear we have separate PS/2 ports for a mouse and keyboard, a DVI-D video output, four USB 2.0 ports, two USB 3.0 ports, gigabit Ethernet, three audio jacks, and the power connector. For additional connectivity, an 802.11ac 1x1 Intel AC3165 is used with internal antennas. Bundled in the Chuwi box is a (short) DVI-D to HDMI connector, which kind of gets around the fact that this system doesn’t have HDMI. The power barrel is somewhat oddly sized, and the power brick seems large.

The Huntkey power supply provides the 19V DC input, at 7.9 A, indicating a peak power of 150 W. This is about right for this system, which shows around 105 W at boot, 65 W at idle, 85 W at full CPU load, and ~150W during Borderlands 3.

Getting inside the system requires removing four small screws, and sliding the white panel off. As I slid the panel off to get inside (as anyone would to administer upgrades), the power button fell out as it wasn’t properly attached to the system. At the same time, the power contact off the motherboard that the button activates, along with the power LED, also disconnected and actually broke away. I wasn’t in any way being aggressive with opening the system, however something seems to have gone wrong either at quality validation or shipping.

Inside the system we are greeted with what looks like a substantial cooling system, with a blower fan style exhausted and multiple heatpipes. This actually forms most of the weight of the system, and to Chuwi’s credit, is almost whisper quiet even during high loading and high thermal scenarios. The only time the fan wasn’t whisper quiet was during a separate issue with the booting sequence, and at 100% fan it is loud. But Chuwi’s fan curve seems to keep it near silent across any workload.

On the left is a 2.5-inch drive bay for a user to add extra storage, and Chuwi has actually provided the SATA data cable and additional SATA power connector in order to do so. That’s a small touch I quite like. The 19 V DC input for power is this thing on the bottom, connected to the 24-pin power connector.

It provides the board with power, an additional 8-pin CPU connector, and an extra SATA power for storage. It can get quite warm during use.

On the right we see two SATA ports (compared to the non-Chuwi version, which has four), two additional internal USB 2.0 headers, and a TPM header, likely for Chuwi’s commercial customers. There is a small chipset heatsink, an M.2-2280 slot for a SATA SSD, and an M.2 Wi-Fi slot just above it.

This is the SSD that came preinstalled – it’s a simple budget 256 GB SATA SSD. At least it is an SSD at any rate!

The Wi-Fi module wasn’t so carefully chosen. Intel’s AC3165 is essentially the cheapest 802.11ac 1x1 solution in the market, and it performed rather well, but rather than spend an extra tenth of a cent on a screw to fix it to the motherboard in its designated hole, For whatever reason it was glued in with a fresh dollop of adhesive, or what might colloquially be known in electrical engineering as hot snot.

So now we get to the processor and what lies underneath the massive heatsink.

If your first reaction to this is one of disgust, then don’t look at this next photo.

Never in my time as a hardware reviewer have I seen such a poor job with thermal paste on a commercial system. Chuwi gets bonus points as this looks like a good silver based paste rather than silicone, but then loses them all as it is likely very conductive and is shorting out all the capacitor pins on the top of the APU. Someone has gone in and said ‘we need to use a minimum of’ and specified a weight of thermal paste (presumably in kilos), regardless of whether it is actually useful or not. I mean, I could enumerate the ways in which this is horrendously bad for Chuwi, but they’re a big enough company, they should know this.

Suffice to say, I had to clean it up. This was perhaps one of the longest thermal paste removals I’ve ever done. It’s time for a montage.


Music provided royalty-free by Orion Williams

After the process was done, I posted about this on Twitter. It was suggested I could have perhaps also used an old toothbrush to help. But here’s the end result.

I replaced the paste with our trusty Noctua NT-H2, reapplied the heatsink, and scored good lower temperatures. Previously when the system would achieve 75ºC (full sustained load, but still top frequency), I was now seeing 62-68ºC.

 

BIOS

Users familiar with newer UEFI systems will be used to a fully graphical interface. Chuwi keeps the system basic with the default black and blue system. There isn’t much to do in the BIOS here; Chuwi set the frequency to 2.35 GHz at all times, there are no fan controls, and the most the user can do is adjust the boot order.

This system does technically have a PCIe slot, so if a user wanted to have a different chassis, then the integrated graphics can be changed. Chuwi has the integrated graphics set as the forced graphics mode, with the maximum frame buffer size.

Installing Windows on an Xbox One APU Gaming Performance: Integrated Graphics
Comments Locked

101 Comments

View All Comments

  • FunBunny2 - Thursday, December 24, 2020 - link

    "also remember how tightly optimized you can get with your code when you know the hardware and also when you can code to the hardware without needing to worry so much about abstraction layers, other overhead and DRM that a publisher might slap on after you've already optimized the game."

    you can thank Mitch for writing 1-2-3 only to 8086 assembler and DOS. from that gossamer layer of an 'operating system' we got neato games and viruses that happily fiddled the hardware.
  • Flunk - Thursday, December 24, 2020 - link

    I'm hoping the new consoles will bring better AI and interactivity because they have massively better CPUs than the previous generation.
  • StuntFriar - Thursday, December 24, 2020 - link

    I was working in a dev studio at the time that was using its own in-house engine for a series of niche sports titles (Cricket, Rugby, etc...) and we couldn't believe how weak the Jaguar cores were compared to the PowerPC cores on the PS3 and 360.

    The GPUs on the PS4 and XBone were obviously superior but we were heavily bottlenecked on the CPU side, because our engine made use of a managed Lua interpreter for all of our game scripting (basically, the majority of gameplay code) which ran on the main thread.

    These were games that easily ran at 30fps on a PS3 which were now struggling to hit 15fps on an XBone. The team had to port a lot of the Lua to native C++ code, as well as a huge amount of other optimisations to get it running well.
  • Jorgp2 - Friday, December 25, 2020 - link

    War?

    These 8 out of order Jaguar cores should be an order of magnitude faster than the in order core of the PS3.
  • StuntFriar - Saturday, December 26, 2020 - link

    As a whole, yes. Core for core, the old PPC cores on the PS3 and 360 were faster at some things.

    Most game engines in 2010 were heavily single-threaded with only a few things handled on other threads. If you were migrating to the PS4 and XBone, there was usually a fair bit of work to do.
  • lmcd - Sunday, December 27, 2020 - link

    PS3 had 2 PPE cores and 6 SPE cores. The 2 PPE cores certainly exceeded Jaguar cores for interpreted workloads, considering how narrow Jaguar designs are, how limited their cache was/is, and the fact that (IIRC) a Jaguar core's out of order depth is lower than that of a PPE PowerPC core.
  • at_clucks - Saturday, December 26, 2020 - link

    @StuntFriar, the reason PS3 games may have issues when running on the Jaguar is the same why they may have issues running on much faster x86 CPUs, and the reason many console games run like crap on much faster PCs. The porting isn't perfect (read "they're many times a mess") and the Cell CPU in the PS3 is very different from x86. Devs had a bad time writing for the PS3 so "porting" usually meant "rewrite from scratch". Now why rewrite a particular game to hit the 1:1 between the PS3 and the next gen consoles when the latter could vastly outperform the PS3 in every regard so you'd actually go for much higher targets? And many of the inexperienced devs that tried to just port PS3 to x86 1:1 of course had an even worse time because they were trying to "adapt" PS3 code to run on something vastly diffrent. Maybe let us know what games ran 30FPS on PS3 but were "struggling" to hit 15FPS on XBone (I know of absolutely no game that runs at 15FPS on XBone). But you were a dev back then so I'm sure you know all this ;).

    The PS3 was a dead end from a programming perspective so any attempts to "port" instead of rewrite was destined to fail badly especially at the hands of the average code monkey. There are things that run great on paper but "porting" them to a digital computer is not that great if you *really* want to replicate everything 1:1. Rewriting has a reason.

    It's like saying you could easily hit 30Km/h on a bicycle but on a motorcycle you can barely hit 2Km/h while pedaling the wheels with your own 2 feet just like on the bicycle, proof that motorcycles are slower.
  • StuntFriar - Saturday, December 26, 2020 - link

    We didn't release the game at 15fps on PS4/XBone - we optimised it so that it ran better.

    Read what I wrote again. We had a managed Lua VM running on the main thread. This is typically fine because the single Power PC core on the Cell processor (or each of the equivalent ones on the 360) was strong enough to run it along with the C++ main game thread.

    A single Jaguar core couldn't match it, which is why we had to rely less on Lua and ported most of it to C++. The engine guys also did some optimisations to spread some of the work across the other cores - the engine also ran on the 360 and already farmed off stuff like animation on a separate thread. I don't know the exact details because I wasn't on that project but they got it together in the end and it ran fine on PS4 and XBone when released.
  • at_clucks - Tuesday, December 29, 2020 - link

    It's like saying that gas is better than electric because you tried putting gas in your battery and it couldn't handle it. Yes, the Jaguar cores can;t handle code that was written and optimized specifically for some completely different type of core. No wonder most people consider game devs bottom of the barrel devs: very little understanding in general, very low quality code. And before you argue read what you wrote again. And think if you'd want any software to run with the same kind of glitches and crashes games do.
  • at_clucks - Tuesday, December 29, 2020 - link

    And just to not leave you hanging since you won't reach the conclusion yourself, the recent Xbox 8 core Jaguar sits at ~150GFLOPS. Which is... almost exactly what the Cell could do. And I won't get into integer performance where the Cell still pretty much used an abacus. Now given the difficulties to actually optimize for the Cell since good game devs are rarer then hen's teeth, pretty much no game got close to that while in x86 even code monkeys could do it.

    It's relatively hard to compare *CPU to CPU* since the Cell and AMD's APUs are very different. But they switched to x86 because it was better in all shapes and forms, better power, better performance, and you could actually get that performance even with code monkeys. And it's a good thing they did, even with ~15 years of (claimed) hindsight your understanding is still that code written and optimized for one architecture and design ran poorly when straight up ported to another one that was as different as they could get.

Log in

Don't have an account? Sign up now