performance

Last month, I built an all-AMD PC to try out Linux Gaming with Steam and Proton, and so I'd have a faster native Linux build machine for my various compilation tasks.

This month, Apple introduced the Mac Studio, and as a now full-time video producer, it was a no-brainer for me to upgrade from an M1 Mac mini.

My Mac Studio arrived Friday, and over the weekend, I spent some time benchmarking it against not only my M1 mini, but also my new AMD Ryzen 5 5600x PC build.

My Mac Studio's specs:

Docker for Mac's shared volume performance saga continues!

After monitoring the issue File system performance improvements for years (discussion has moved to this issue now), it seems like the team behind Docker Desktop for Mac has finally settled on the next generation of filesystem sync.

For years, the built-in osxfs sync performance has been abysmal. For a Drupal developer like me, running a default shared volume could lead to excruciating slowdowns as PHP applications like Symfony and Drupal scan thousands of files when building app caches.

Or God forbid you ever have to install dependencies using Composer or NPM over a shared volume!

It got to the point where I started using NFS to speed up volume performance. Heck, the Docker team almost added Mutagen sync, which I tested successfully, but it caused problems for too many projects.

Since the Raspberry Pi Compute Module 4 was introduced last year, I've been testing a variety of PCI Express NICs with it. One of the main types of NIC I'm interested in is cheap 2.5 Gigabit Ethernet adapters.

2.5 Gigabits is about the highest reasonable bandwidth you can get through the PCI Express Gen 2.0 x1 lane on the Raspberry Pi, and it's also a lot more accessible than 10 Gigabit networking, especially for home users who might already have Cat5e runs that they are loathe to swap out for Cat6 or better cabling.

In my testing, besides discovering that not all 10 Gbps SFP+ transceivers are created equal, I found out that when it comes to performance, the Linux driver you're using matters—a lot.

This is a simple guide, part of a series I'll call 'How-To Guide Without Ads'. In it, I'm going to document how I set up bcache on a Raspberry Pi, so I could use an SSD as a cache in front of a RAID array.

Getting bcache

bcache is sometimes used on Linux devices to allow a more efficient SSD cache to run in front of a single or multiple slower hard drives—typically in a storage array.

In my case, I have three SATA hard drives: /dev/sda, /dev/sdb, and /dev/sdc. And I have one NVMe SSD: /dev/nvme0n1.

I created a RAID5 array with mdadm for the three hard drives, and had the raid device /dev/md0.

I then installed bcache-tools:

$ sudo apt-get install bcache-tools

And used make-bcache to create the backing and cache devices:

I didn't know it at the time, but my results testing the EDUP WiFi 6 card (which uses the Intel AX200 chipset) on the Raspberry Pi in December weren't accurate.

It doesn't get 1.34 gigabits of bandwidth with the Raspberry Pi Compute Module 4 like I stated in my December video, WiFi 6 on the Raspberry Pi CM4 makes it Fly!.

I'm very thorough in my benchmarking, and if there's ever a weird anomaly, I try everything I can to prove or disprove the result before sharing it with anyone.

In this case, since I was chomping at the bit to move on to testing a Rosewill 2.5 gigabit Ethernet card, I didn't spend as much time as I should have re-verifying my results.

I got this Rosewill RC-20001 PCIe 2.5 Gbps Network Adapter working on the Raspberry Pi Compute Module 4.

Right after I got the card working, though, I tested it in an external powered PCI Express riser, and that test released the card's magic smoke. Oops.

Here's a dramatic re-enactment that's actually pretty accurate to what it looked like in real life:

Luckily, buying a replacment wasn't too bad, since the card is less than $20. But to get it to work on my spiffy new ten gigabit network, I also had to buy a new SFP+ transceiver that was compatible with 1, 2.5, 5, and 10 Gbps data rates, and that cost $60!

January 1, 2021 Update: My 1.34 Gbps benchmark was flawed. See this GitHub issue and this updated blog post to learn more: WiFi 6 is not faster than Ethernet on the Raspberry Pi.

After buying three wireless cards, a new WiFi router, optimizing my process for cross-compiling the Linux kernel for the Raspberry Pi, installing Intel's WiFi firmware, and patching Intel's wireless driver to make it work on the Raspberry Pi, I benchmarked the EDUP Intel AX200 WiFi 6 PCIe card and got 1.34 Gbps of bandwidth between the Raspberry Pi and a new ASUS WiFi 6 router.

This is my story.

After the Raspberry Pi 400 was launched earlier this morning, there was a lot of discussion over the thermals and performance of the upgraded 1.8 GHz System on a Chip inside:

I wanted to spend a little time in this post testing overclocking, performance, power consumption, and thermals in depth.

Video version

There is also a video that goes along with this post, if you're more visually-inclined:

People have been overclocking Raspberry Pis since the beginning of time, and the Raspberry Pi 4 is no exception.

I wanted to see if the Compute Module 4 (see my full review here) could handle overclocking the same way, and how fast I could get mine to run without crashing.

There's a video version of this blog post, if you'd like to watch that instead:
Raspberry Pi Compute Module 4 OVERCLOCKED.

In the past few weeks, I reviewed USB drive performance on the Raspberry Pi 4, and the importance of UASP support for USB drive performance.

Both posts generated great discussion, and there were three things I wanted to cover in this follow-up, namely:

1. Which drives support UASP
2. Real-world performance benchmarks
3. TRIM support

For reference, here are all the products I'm testing in this post (product links are to their Amazon product page, starting from top middle, clockwise):