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.
Six years ago, the Raspberry Pi Foundation introduced the Compute Module: a teensy-tiny version of the popular Raspberry Pi model B board.
Between then and now, there have been multiple revisions to the Compute Module, like the 3+ I used in my Raspberry Pi Cluster YouTube series, but they've all had the same basic form factor and a very limited feature set.
But today, that all changes with the fourth generation of the compute module, the Compute Module 4! Here's a size comparison with the previous-generation Compute Module 3+, some other common Pi models, and an SD and microSD card (remember when the original Pi used a full-size SD card?):
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:
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):
Over the weekend, Nvidia confirmed it would purchase ARM from Softbank for $40 billion.
Now, what is ARM, why is Nvidia buying it, and what does any of this have to do with the Raspberry Pi?
Well, let's start with ARM.
This blog post also has a video version to go along with it.
ARM can refer to a number of things, but let's start by talking about the company, Arm Holdings. They have lineage dating back to Acorn computers, a British computer manufacturer founded in the late 1970s that designed the first 'Acorn RISC Machine architecture' chips, AKA 'ARM'.
Something I've long been meaning to benchmark, but never really got around to, is benchmarking the amount of time it takes on a Raspberry Pi to open a browser, load a page, and quit.
This is a relatively decent thing to benchmark, compared to other raw performance metrics, because it's something that probably 99% of Raspberry Pi users who use it with a GUI will do, with some frequency (well, probably loading more than one page before quitting, but still...).
So I asked on Twitter:
So... if I want to measure how long it takes to:
1 Open Chrome/Chromium
2 Load a web page
And I want to do this in Linux (Debian), and have an objective measure of that time (until the page finishes loading)... is there any way to do that?
CLI opens then sits until you quit.
I've been doing a lot of benchmarking and testing with the Raspberry Pi 4 and SSDs connected via USB. I explored UASP Support, which USB SSDs are the fastest, and I'm now booting my Pis from USB SSDs.
Anyways, one thing that I have wondered about—and some people have asked me about—is TRIM support.
I'm working on a new video for my YouTube channel that will go into some more detail on which of the drives I tested support TRIM, but while I was researching for that video, I also found that TRIM support in Linux is not as simple as it seems at first glance—it's definitely not plug-and-play, in my experience.
While internal microSD cards seem to support TRIM out of the box, none of the external USB drives I tested supported it out of the box. They all needed a little help!
Today I posted the first episode of a new series on the Raspberry Pi High Quality Camera.
I plan on releasing a number of videos in the series covering how to use the HQ camera in various settings, like for astrophotography, nature photography and video, as a webcam or for streaming, for time-lapse photography, and for general photography.
I'll be updating this post with all the videos as I publish them:
For years, I've been maintaining benchmarks for microSD cards on the Raspberry Pi, but I only spent a little time testing external USB storage, due to historic limitations with the Pi's USB 2.0 bus.
But the Pi 4 cleared away the limitations with a full-speed USB 3.0 bus offering much better performance, so I've done a lot of testing with USB boot, and with all the USB SSDs I had at my disposal. You can see some of those results in this blog post and video on booting a Pi 4 via USB.
After posting my tests concerning UASP support in USB SATA adapters, I got an email from Rob Logan mentioning the performance of some other types of drives he had with him. And he even offered to ship a few drives to me for comparisons!
There's also a video that accompanies this blog post, for the more visually-inclined:
A few months ago, in the 'before times', I noticed this post on Hacker News mentioning the Turing Pi, a 'Plug & Play Raspberry Pi Cluster' that sits on your desk.
It caught my attention because I've been running my own old-fashioned 'Raspberry Pi Dramble' cluster since 2015.
So today, I'm wrapping up my Raspberry Pi Cluster series with my thoughts about the Turing Pi that I used to build a 7-node Kubernetes cluster.
This blog post has a companion video embedded below:
There is a companion video to this post: Is fast NVMe storage coming to the Raspberry Pi?.
A couple days ago, Tom's Hardware posted an article stating NVMe support might be coming to the Raspberry Pi Compute Module 4.
On the first episode of The Pi Cast, Eben Upton, the CEO of Raspberry Pi, said "microSD will always be the baseline for storage", but "it's fairly likely we'll support NVMe soon on the Compute Module 4, to some degree, using single-lane PCI Express." (Skip to about 11 minutes into the video for the NVMe discussion).
He also said NVMe support is not without cost, since there's an extra connector silicon required. And with the System on a Chip used in the Pi 4, there's also a tradeoff involved: There's only one PCIe 1x lane, and it's currently used for the Pi 4's USB 3.0. If you want to add NVMe support, you'd have to drop the USB 3.0 ports.