In the pursuit of doing crazy things on a Raspberry Pi, my latest endeavor was to see if I could consistently pipe more than a gigabit per second of traffic through WiFi using a Raspberry Pi.
In the past, I had some faltering attempts where sometimes things would work—sort-of—using WiFi 6 (802.11ax, 40 MHz bandwidth, 2x2) using an Intel AX200 M.2 card on the Raspberry Pi Compute Module 4.
Recently I was doing some benchmarking on my Ubuntu 22.04 PC, and as part of that benchmarking, I tried setting the CPU performance profile to performance. In the old days, this was not an issue, but it seems that modern Ubuntu only 'knows' about balanced and power-saver. Apparently performance is forbidden these days!
$ powerprofilesctl list
* balanced:
Driver: placeholder
power-saver:
Driver: placeholder
The problem was, I had set the profile to performance:
$ powerprofilesctl set performance
But suddenly the 'Settings' GUI app would no longer open (at least not after I had opened it and clicked into the 'power' section). A reboot didn't work, and even reinstalling control center (sudo apt-get install --reinstall gnome-control-center) didn't help!
When I tried opening the settings GUI from the command line, I got the following critical error:
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.
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.
There is also a video that goes along with this post, if you're more visually-inclined: