Preparing a Raspberry Pi#

This guide will walk you through how run a Rocket Pool node using a Raspberry Pi. While this is not typically recommended in most staking guides, we recognize that it is attractive because it is a much more affordable option than standing up an entire PC. To that end, we've worked hard to tweak and optimize a whole host of settings and have determined a configuration that seems to work well.

This setup will run a full Execution node and a full Consensus node on the Pi, making your system contribute to the health of the Ethereum network while simultaneously acting as a Rocket Pool node operator.

Preliminary Setup#

To run a Rocket Pool node on a Raspberry Pi, you'll need to first have a working Raspberry Pi. If you already have one up and running - great! You can skip down to the Mounting the SSD section. Just make sure you have a fan attached before you go. If you're starting from scratch, then read on.

What You'll Need#

These are the recommended components that you'll need to buy in order to run Rocket Pool on a Pi:

• A Raspberry Pi 4 Model B, the 8 GB model
  • Note: while you can use a 4 GB with this setup, we strongly recommend you go with an 8 GB for peace of mind... it's really not much more expensive.
• A USB-C power supply for the Pi. You want one that provides at least 3 amps.
• A MicroSD card. It doesn't have to be big, 16 GB is plenty and they're pretty cheap now... but it should be at least a Class 10 (U1).
• A MicroSD to USB adapter for your PC. This is needed so you can install the Operating System onto the card before loading it into the Pi. If your PC already has an SD port, then you don't need to pick up a new one.
• Some heatsinks. You're going to be running the Pi under heavy load 24/7, and it's going to get hot. Heatsinks will help so it doesn't throttle itself. You ideally want a set of 3: one for the CPU, one for the RAM, and one for the USB controller. Here is a good example of a nice set.
• A case. There are two ways to go here: with a fan, and fanless.
  • With a fan:
    • A 40mm fan. Same as the above, the goal is to keep things cool while running your Rocket Pool node.
    • A case with a fan mount to tie it all together. You could also get a case with integrated fans like this one so you don't have to buy the fans separately.
  • Without a fan:
    • A fanless case that acts as one giant heatsink, like this one. This is a nice option since it's silent, but your Pi will get quite hot - especially during the initial blockchain sync process. Credit to Discord user Ken for pointing us in this direction!
  • As a general rule, we recommend going with a fan because we're going to be overclocking the Pi significantly.

You can get a lot of this stuff bundled together for convenience - for example, Canakit offers a kit with many components included. However, you might be able to get it all cheaper if you get the parts separately (and if you have the equipment, you can 3D print your own Pi case.)

Other components you'll need:

• A USB 3.0+ Solid State Drive. The general recommendation is for a 2 TB drive.
  • The Samsung T5 is an excellent example of one that is known to work well.
  • :warning: Using a SATA SSD with a SATA-to-USB adapter is not recommended because of problems like this. If you go this route, we've included a performance test you can use to check if it will work or not in the Testing the SSD's Performance section.
• An ethernet cable for internet access. It should be at least Cat 5e rated.
  • Running a node over Wi-Fi is not recommended, but if you have no other option, you can do it instead of using an ethernet cable.
• A UPS to act as a power source if you ever lose electricity. The Pi really doesn't draw much power, so even a small UPS will last for a while, but generally the bigger, the better. Go with as big of a UPS as you can afford. Also, we recommend you attach your modem, router, and other network equipment to it as well - not much point keeping your Pi alive if your router dies.

Depending on your location, sales, your choice of SSD and UPS, and how many of these things you already have, you're probably going to end up spending around $200 to $500 USD for a complete setup.

Making the Fan Run More Quietly#

When you get the fan, by default you're probably going to be instructed to connect it to the 5v GPIO pin, as shown in the picture below. The fan will have a connector with two holes; the black one should go to GND (pin 6), and the red one should go to +5v (pin 4).

However, in our experience, this makes the fan run very loud and fast which isn't really necessary. If you want to make it more quiet while still running cool, try connecting it to the 3.3v pin (Pin 1, the blue one) instead of the 5v pin. This means that on your fan, the black point will go to GND (pin 6) still, but now the red point will go to +3.3v (pin 1).

If your fan has a connector where the two holes are side by side and you can't split them apart, you can put some jumpers like this in between it and the GPIO pins on the Pi.

Installing the Operating System#

There are a few varieties of Linux OS that support the Raspberry Pi. For this guide, we're going to stick to Ubuntu 20.04. Ubuntu is a tried-and-true OS that's used around the world, and 20.04 is (at the time of this writing) the latest of the Long Term Support (LTS) versions, which means it will keep getting security patches for a very long time. If you'd rather stick with a different flavor of Linux like Raspbian, feel free to follow the existing installation guides for that - just keep in mind that this guide is built for Ubuntu, so not all of the instructions may match your OS.

The fine folks at Canonical have written up a wonderful guide on how to install the Ubuntu Server image onto a Pi.

Follow steps 1 through 4 of the guide above for the Server setup. For the Operating System image, you want to select Ubuntu Server 20.04.2 LTS (RPi 3/4/400) 64-bit server OS with long-term support for arm64 architectures.

If you decide that you want a desktop UI (so you can use a mouse and have windows to drag around), you'll need to follow step 5 as well. We suggest that you don't do this and just stick with the server image, because the desktop UI will add some additional overhead and processing work onto your Pi with relatively little benefit. However, if you're determined to run a desktop, then we recommend choosing the Xubuntu option. It's pretty lightweight on resources and very user friendly.

Once that's complete, you're ready to start preparing Ubuntu to run a Rocket Pool node. You can use the local terminal on it, or you can SSH in from your desktop / laptop as the installation guide suggests. The process will be the same either way, so do whatever's most convenient for you.

If you aren't familiar with ssh, take a look at the Intro to Secure Shell guide.

Mounting the SSD#

As you may have gathered, after following the above installation instructions, the core OS will be running off of the microSD card. That's not nearly large enough or fast enough to hold all of the Execution and Consensus blockchain data, which is where the SSD comes in. To use it, we have to set it up with a file system and mount it to the Pi.

Connecting the SSD to the USB 3.0 Ports#

Start by plugging your SSD into one of the Pi's USB 3.0 ports. These are the blue ports, not the black ones:

The black ones are slow USB 2.0 ports; they're only good for accessories like mice and keyboards. If you have your keyboard plugged into the blue ports, take it out and plug it into the black ones now.

Formatting the SSD and Creating a New Partition#

Run this command to find the location of your disk in the device table:

sudo lshw -C disk
  *-disk
       description: SCSI Disk
       product: Portable SSD T5
       vendor: Samsung
       physical id: 0.0.0
       bus info: scsi@0:0.0.0
       logical name: /dev/sda
       ...

The important thing you need is the logical name: /dev/sda portion, or rather, the /dev/sda part of it. We're going to call this the device location of your SSD. For this guide, we'll just use /dev/sda as the device location - yours will probably be the same, but substitute it with whatever that command shows for the rest of the instructions.

Now that we know the device location, let's format it and make a new partition on it so we can actually use it. Again, these commands will delete whatever's already on the disk!

Create a new partition table:

sudo parted -s /dev/sda mklabel gpt unit GB mkpart primary ext4 0 100%

Format the new partition with the ext4 file system:

sudo mkfs -t ext4 /dev/sda1

Add a label to it (you don't have to do this, but it's fun):

sudo e2label /dev/sda1 "Rocket Drive"

Confirm that this worked by running the command below, which should show output like what you see here:

sudo blkid
...
/dev/sda1: LABEL="Rocket Drive" UUID="1ade40fd-1ea4-4c6e-99ea-ebb804d86266" TYPE="ext4" PARTLABEL="primary" PARTUUID="288bf76b-792c-4e6a-a049-cb6a4d23abc0"

If you see all of that, then you're good. Grab the UUID="..." output and put it somewhere temporarily, because you're going to need it in a minute.

Optimizing the New Partition#

Next, let's tune the new filesystem a little to optimize it for validator activity.

By default, ext4 will reserve 5% of its space for system processes. Since we don't need that on the SSD because it just stores the Execution and Consensus chain data, we can disable it:

sudo tune2fs -m 0 /dev/sda1

Mounting and Enabling Automount#

In order to use the drive, you have to mount it to the file system. Create a new mount point anywhere you like (we'll use /mnt/rpdata here as an example, feel free to use that):

sudo mkdir /mnt/rpdata

Now, mount the new SSD partition to that folder:

sudo mount /dev/sda1 /mnt/rpdata

After this, the folder /mnt/rpdata will point to the SSD, so anything you write to that folder will live on the SSD. This is where we're going to store the chain data for Execution and Consensus.

Now, let's add it to the mounting table so it automatically mounts on startup. Remember the UUID from the blkid command you used earlier? This is where it will come in handy.

sudo nano /etc/fstab

This will open up an interactive file editor, which will look like this to start:

Use the arrow keys to go down to the bottom line, and add this line to the end:

Replace the value in UUID=... with the one from your disk, then press Ctrl+O and Enter to save, then Ctrl+X and Enter to exit. Now the SSD will be automatically mounted when you reboot. Nice!

Testing the SSD's Performance#

Before going any further, you should test your SSD's read/write speed and how many I/O requests it can handle per second (IOPS). If your SSD is too slow, then it won't work well for a Rocket Pool node and you're going to end up losing money over time.

To test it, we're going to use a program called fio. Install it like this:

sudo apt install fio

Next, move to your SSD's mount point:

cd /mnt/rpdata

Now, run this command to test the SSD performance:

sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

The output should look like this:

What you care about are the lines starting with read: and write: under the test: line.

• Your read should have IOPS of at least 15k and bandwidth (BW) of at least 60 MiB/s.
• Your write should have IOPS of at least 5000 and bandwidth of at least 20 MiB/s.

Those are the specs from the Samsung T5 that we use, which work very well. We have also tested a slower SSD with read IOPS of 5k and write IOPS of 1k, and it has a very hard time keeping up with the consensus layer. If you use an SSD slower than the specs above, just be prepared that you might see a lot of missed attestations. If yours meets or exceeds them, then you're all set and can move on.

Last but not least, remove the test file you just made:

sudo rm /mnt/rpdata/test

Setting up Swap Space#

The Pi has 8 GB (or 4 GB if you went that route) of RAM. For our configuration, that will be plenty. Then again, it never hurts to add a little more. What we're going to do now is add what's called swap space. Essentially, it means we're going to use the SSD as "backup RAM" in case something goes horribly, horribly wrong and the Pi runs out of regular RAM. The SSD isn't nearly as fast as the regular RAM, so if it hits the swap space it will slow things down, but it won't completely crash and break everything. Think of this as extra insurance that you'll (most likely) never need.

Creating a Swap File#

The first step is to make a new file that will act as your swap space. Decide how much you want to use - a reasonable start would be 8 GB, so you have 8 GB of normal RAM and 8 GB of "backup RAM" for a total of 16 GB. To be super safe, you can make it 24 GB so your system has 8 GB of normal RAM and 24 GB of "backup RAM" for a total of 32 GB, but this is probably overkill. Luckily, since your SSD has 1 or 2 TB of space, allocating 8 to 24 GB for a swapfile is negligible.

For the sake of this walkthrough, let's pick a nice middleground - say, 16 GB of swap space for a total RAM of 24 GB. Just substitute whatever number you want in as we go.

Enter this, which will create a new file called /mnt/rpdata/swapfile and fill it with 16 GB of zeros. To change the amount, just change the number in count=16 to whatever you want. Note that this is going to take a long time, but that's ok.

sudo dd if=/dev/zero of=/mnt/rpdata/swapfile bs=1G count=16 status=progress

Next, set the permissions so only the root user can read or write to it (for security):

sudo chmod 600 /mnt/rpdata/swapfile

Now, mark it as a swap file:

sudo mkswap /mnt/rpdata/swapfile

Next, enable it:

sudo swapon /mnt/rpdata/swapfile

Finally, add it to the mount table so it automatically loads when your Pi reboots:

sudo nano /etc/fstab

Add a new line at the end so that the file looks like this:

Press Ctrl+O and Enter to save, then Ctrl+X and Enter to exit.

To verify that it's active, run these commands:

sudo apt install htop
htop

Your output should look like this at the top:

If the second number in the last row labeled Swp (the one after the /) is non-zero, then you're all set. For example, if it shows 0K / 16.0G then your swap space was activated successfully. If it shows 0K / 0K then it did not work and you'll have to confirm that you entered the previous steps properly.

Press q or F10 to quit out of htop and get back to the terminal.

Configuring Swappiness and Cache Pressure#

By default, Linux will eagerly use a lot of swap space to take some of the pressure off of the system's RAM. We don't want that. We want it to use all of the RAM up to the very last second before relying on SWAP. The next step is to change what's called the "swappiness" of the system, which is basically how eager it is to use the swap space. There is a lot of debate about what value to set this to, but we've found a value of 6 works well enough.

We also want to turn down the "cache pressure", which dictates how quickly the Pi will delete a cache of its filesystem. Since we're going to have a lot of spare RAM with our setup, we can make this "10" which will leave the cache in memory for a while, reducing disk I/O.

To set these, run these commands:

sudo sysctl vm.swappiness=6
sudo sysctl vm.vfs_cache_pressure=10

Now, put them into the sysctl.conf file so they are reapplied after a reboot:

sudo nano /etc/sysctl.conf

Add these two lines to the end:

vm.swappiness=6
vm.vfs_cache_pressure=10

Then save and exit like you've done before (Ctrl+O, Ctrl+X).

Overclocking the Pi#

By default, the 1.5 GHz processor that the Pi comes with is a pretty capable little device. For the most part, you should be able to validate with it just fine. However, we have noticed that on rare occasions, your validator client gets stuck working on some things and it just doesn't have enough horsepower to keep up with your validator's attestation duties. When that happens, you'll see something like this on the beaconcha.in explorer (described in more detail in the Monitoring your Node's Performance guide later on):

That inclusion distance of 8 means that it took a really long time to send that attestation, and you will be slightly penalized for being late. Ideally, all of them should be 0. Though rare, these do occur when running at stock settings.

There is a way to mitigate these, however: overclocking. Overclocking is by far the easiest way to get some extra performance out of your Pi's CPU and prevent those nasty high inclusion distances. Frankly, the default CPU clock of 1.5 GHz is really underpowered. You can speed it up quite a bit via overclocking, and depending on how far you take it, you can do it quite safely too.

Overclocking the Pi is very simple - it just involves changing some numbers in a text file. There are two numbers that matter: the first is the core clock, which directly determines how fast the ARM CPU runs. The second is overvoltage, which determines the voltage that gets fed into the ARM CPU. Higher speeds generally require higher voltage, but the Pi's CPU can handle quite a bit of extra voltage without any appreciable damage. It might wear out a little faster, but we're still talking on the order of years and the Pi 5 will be out by then, so no real harm done!

Rather, the real concern with overvoltage is that higher voltages lead to higher temperatures. This section will help you see how hot your Pi gets under a heavy load, so you don't push it too far.

Benchmarking the Stock Configuration#

Before overclocking, your should profile what your Pi is capable of in its stock, off-the-shelf configuration. There are three key things to look at:

1. Performance (how fast your Pi calculates things)
2. Temperature under load (how hot it gets)
3. Stability (how long it runs before crashing)

We're going to get stats on all three of them as we go.

Performance#

For measuring performance, you can use LINPACK. We'll build it from source.

cd ~
sudo apt install gcc
wget http://www.netlib.org/benchmark/linpackc.new -O linpack.c
...
cc -O3 -o linpack linpack.c -lm
...
sudo mv linpack /usr/local/bin
rm linpack.c

Now run it like this:

linpack
Enter array size (q to quit) [200]:

Just press enter to leave it at the default of 200, and let it run. When it's done, the output will look like this:

What you need to look at is the last row, in the KFLOPS column. This number (1120277.186 in the above example) represents your computing performance. It doesn't mean anything by itself, but it gives us a good baseline to compare the overclocked performance to. Let's call this the stock KFLOPS.

Temperature#

Next, let's stress the Pi out and watch its temperature under heavy load. First, install this package, which will provide a tool called vcgencmd that can print details about the Pi:

sudo apt install libraspberrypi-bin

Once this is installed, reboot the Pi (this is necessary for some new permission to get applied). Next, install a program called stressberry. This will be our benchmarking tool. Install it like this:

sudo apt install stress python3-pip
pip3 install stressberry
source ~/.profile

sudo usermod -aG video $USER

Next, run it like this:

stressberry-run -n "Stock" -d 300 -i 60 -c 4 stock.out

This will run a new stress test named "Stock" for 300 seconds (5 minutes) with 60 seconds of cooldown before and after the test, on all 4 cores of the Pi. You can play with these timings if you want it to run longer or have more of a cooldown, but this works as a quick-and-dirty stress test for me. The results will get saved to a file named stock.out.

During the main phase of the test, the output will look like this:

This basically tells you how hot the Pi will get. At 85­°C, the Pi will actually start to throttle itself and bring the clock speed down so it doesn't overheat. Luckily, because you added a heatsink and a fan, you shouldn't get anywhere close to this! That being said, we generally try to keep the temperatures below 65°C for the sake of the system's overall health.

If you want to monitor the system temperature during normal validating operations, you can do this with vcgencmd:

vcgencmd measure_temp
temp=34.0'C

Stability#

Testing the stability of an overclock involves answering these three questions:

• Does the Pi turn on and get to a login promp / start the SSH server?
• Does it randomly freeze or restart during normal operations?
• Does it randomly freeze or restart during heavy load?

For an overclock to be truly stable, the answers must be yes, no, and no. There are a few ways to test this, but the easiest at this point is to just run stressberry for a really long time. How long is entirely up to you - the longer it goes, the more sure you can be that the system is stable. Some people just run the 5 minute test above and call that good if it survives; others run it for a half hour; others run it for 8 hours or even more. How long to run it is a personal decision you'll have to make based on your own risk tolerance.

To change the runtime, just modify the -d parameter with the number of seconds you want the test to run. For example, if you decided a half-hour is the way to go, you could do -d 1800.

Your First Overclock - 1800 MHz (Light)#

The first overclock we're going to do is relatively "light" and reliable, but still provides a nice boost in compute power. We're going to go from the stock 1500 MHz up to 1800 MHz - a 20% speedup!

Open this file:

sudo nano /boot/firmware/usercfg.txt

Add these two lines to the end:

arm_freq=1800
over_voltage=3

Then save the file and reboot.

These settings will increase the CPU clock by 20%, and it will also raise the CPU voltage from 0.88v to 0.93v (each over_voltage setting increases it by 0.025v). This setting should be attainable by any Pi 4B, so your system should restart and provide a login prompt or SSH access in just a few moments. If it doesn't, and your Pi stops responding or enters a boot loop, you'll have to reset it - read the next section for that.

Resetting After an Unstable Overclock#

If your Pi stops responding, or keeps restarting over and over, then you need to lower the overclock. To do that, follow these steps:

1. Turn the Pi off.
2. Pull the microSD card out.
3. Plug the card into another Linux computer with a microSD adapter. *NOTE: This has to be another Linux computer. It won't work if you plug it into a Windows machine, because Windows can't read the ext4 filesystem the SD card uses!**
4. Mount the card on the other computer.
5. Open <SD mount point>/boot/firmware/usercfg.txt.
6. Lower the arm_freq value, or increase the over_voltage value. NOTE: do not go any higher than over_voltage=6. Higher values aren't supported by the Pi's warranty, and they run the risk of degrading the CPU faster than you might be comfortable with.
7. Unmount the SD card and remove it.
8. Plug the card back into the Pi and turn it on.

If the Pi works, then great! Continue below. If not, repeat the whole process with even more conservative settings. In the worst case you can just remove the arm_freq and over_voltage lines entirely to return it to stock settings.

Testing 1800 MHz#

Once you're logged in, run linpack again to test the new performance. Here's an example from our test Pi:

Again, grab the KFLOPS column in the last row. To compare it to the stock configuration, simply divide the two numbers: 1337238.504 / 1120277.186 = 1.193668

Alright! That's a 19.4% boost in performance, which is to be expected since we're running 20% faster. Now let's check the temperatures with the new clock speed and voltage settings:

stressberry-run -n "1800_ov3" -d 300 -i 60 -c 4 1800_ov3.out

You should see output like this:

Not bad, about 6° hotter than the stock settings but still well below the threshold where we'd personally stop.

You can run a longer stability test here if you're comfortable, or you can press on to take things even higher.

Going to 2000 MHz (Medium)#

The next milestone will be 2000 MHz. This represents a 33.3% boost in clock speed, which is pretty significant. Most people consider this to be a great balance between performance and stability, so they stop the process here.

Our recommendation for this level is to start with these settings:

arm_freq=2000
over_voltage=5

This will boost the core voltage to 1.005v. Try this out with the linpack and stressberry tests. If it survives them, then you're all set. If it freezes or randomly restarts, then you should increase the voltage:

arm_freq=2000
over_voltage=6

That puts the core voltage at 1.03v, which is as high as you can go before voiding the warranty. That usually works for most Pis. If it doesn't, instead of increasing the voltage further, you should lower your clock speed and try again.

For reference, here are the numbers from our 2000 run:

That's a 32.3% speedup which is in-line with what we'd expect. Not bad!

Here are our temperatures:

An increase of 7 more degrees, but still under our threshold of 65°C.

Going to 2100 MHz (Heavy)#

The next step represents a solid 40% speedup over the stock configuration.

NOTE: Not all Pi's are capable of doing this while staying at over_voltage=6. Try it, and if it breaks, go back to 2000 MHz.

The configuration will look like this:

arm_freq=2100
over_voltage=6

For reference, here are our results:

That's a 39.4% speedup!

Here are our temperatures:

Just shy of 60°C, so there's plenty of room.

Going to 2250 MHz (Extreme)#

This is the setting we run our Pi's at, which has been stable for over a year at the time of writing. Still, users are cautioned in overclocking this high - ensure you do thorough stability tests and have plenty of thermal headroom before attempting to make this your node's production configuration!

Our configuration is:

arm_freq=2250
over_voltage=10

Here are our results:

That's 46% faster than the stock configuration!

OV10 is as the stock firmware will let the Pi go, and 2250 MHz is the fastest we could reliably run in production.

The temperatures in the stress test get this high:

But during actual validation, they tend to stay below 60C which is acceptable for us.

Next Steps#

And with that, your Pi is up and running and ready to run Rocket Pool! Move on to the Choosing your ETH Clients section.