benchmarking

Ubuntu's settings won't open after setting CPU to 'performance'

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:

Benchmarking DNS on my Mac with Pi-Hole

After watching Level1Techs' THE FORBIDDEN ROUTER II - DIAL-UP BY DAWN video, I wanted to do some DNS benchmarking on my local network.

Since I run Pi-hole locally, and rely on it for local DNS resolution, I wanted to have a baseline so I could compare performance over time.

In the video, Wendell mentioned the use of Gibson's Windows-only DNS Benchmark tool. But that's Windows-only. Or maybe Linux under WINE, but definitely not a native / open source tool that's easily used across different platforms.

I looked around and settled on bulldohzer—for now, at least—as it's easy to install anywhere Node.js runs. I have Node.js installed via Homebrew on my Mac, so I just ran:

npm install --location=global bulldohzer

Then I could run a benchmark against Google and my own local DNS resolver (Pi-Hole):

Network interface routing priority on a Raspberry Pi

52Pi Raspberry Pi Compute Module 4 Router Board

As I start using Raspberry Pis for more and more network routing activities—especially as the Compute Module 4 routers based on Debian, OpenWRT, and VyOS have started appearing—I've been struggling with one particular problem: how can I set routing priorities for network interfaces?

Now, this is a bit of a loaded question. You could dive right into routing tables and start adding and deleting routes from the kernel. You could mess with subnets, modify firewalls, and futz with iptables.

But in my case, my need was simple: I wanted to test the speed of a specific interface, either from one computer to another, or over the Internet (e.g. via speedtest-cli).

The problem is, even if you try limiting an application to a specific IP address (each network interface has its own), the Linux kernel will choose whatever network route it deems the best.

Check your driver! Faster Linux 2.5G Networking with Realtek RTL8125B

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.

WiFi 6 is not faster than Ethernet on the Raspberry Pi

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.

MZHOU WiFi Bluetooth M.2 NGFF Adapter Card for PCIe Raspberry Pi Compute Module 4 AX200 Intel 6

Testing 2.5 Gbps Ethernet on the Raspberry Pi CM4

Rosewill 2.5 Gbps Ethernet adapter PCIe 1x card

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:

PCIe card lets out magic smoke

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!

Setting 9000 MTU (Jumbo Frames) on Raspberry Pi OS

Raspberry Pi OS isn't really built to be a server OS; the main goals are stability and support for educational content. But that doesn't mean people like me don't use and abuse it to do just about anything.

In my case, I've been doing a lot of network testing lately—first with an Intel I340-T4 PCIe interface for 4.15 Gbps of networking, and more recently (yesterday, in fact!) with a Rosewill 2.5 GbE PCIe NIC.

And since the Pi's BCM2711 SoC is somewhat limited, it can't seem to pump through many Gbps of bandwidth without hitting IRQ limits, and queueing up packets.

In the case of the 2.5G NIC, I was seeing it max out around 1.92 Gpbs, and I just wouldn't accept that (at least not for a raw benchmark). Running atop, I noticed that during testing, the IRQ interrupts would max out at 99% on one CPU core—and it seems like it may be impossible to distribute interrupts across all four cores on the BCM2711.

Testing how long it takes Chromium to open, load a web page, and quit on Debian

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:

Raspberry Pi Cluster Episode 5 - Benchmarking the Turing Pi

At this point, I've showed you how you can use the Turing Pi as a Kubernetes cluster to run different things. I barely scratched the surface of what's possible with Kubernetes, but I'm planning on doing another series exploring Kubernetes itself later this year. Subscribe to my YouTube channel if you want to see it!

In this post, I'm going to talk about the Turing Pi's performance. I'll compare it to a more traditional Raspberry Pi cluster, my Pi Dramble, and talk about important considerations for your cluster, like what kind of storage you should use, or whether you should run a 32-bit or 64-bit Pi operating system.

As with all the other work I've done on this cluster, I've been documenting it all in my open source Turing Pi Cluster project on GitHub.

Video version of this post

This blog post has a companion video embedded below:

Benchmarking PHP 7 vs HHVM - Drupal and Wordpress

[Multiple updates: I've added results for concurrencies of 1 and 10, results on bare metal vs. VMware instances, tested Drupal 8 vs Drupal 7 vs Wordpress 4.4, and I've also retested every single benchmark at least twice! Please make sure you're read through the entire post prior to contesting these benchmark results!]

tl;dr: Always test your own application, and trust, but verify every benchmark you see. PHP 7 is actually faster than HHVM in many cases, neck-in-neck in others, and slightly slower in others. Both PHP 7 and HHVM blow PHP ≤ 5.6 out of the water.

Skip to benchmark results: