Terrible Cluster

5 Raspberry PI Zeros. One custom USB hub. Endless disappointment.

Similar projects worth following
Terrible Cluster is a toy computing cluster for experimenting with distributed computing and software deployment tools. The Terrible Cluster backplane board uses USB 2.0 to tie together five Raspberry Pi Zeros in a compact package. Total cost unassembled is around $100, half of which is SD cards.

The author does not expect that this will be of any benefit to society. I mean, maaaaybe someone could learn something about cluster computing, networking, USB, or hardware design, with their very own palm sized cluster. But only as a cautionary tale.

Please keep any advice about cluster simulation with multiple VMs, dumpster diving for free PCs, alternative interconnects, complaints about Pi availability, and how I'm contributing to the decline of humanity to yourself. I don't call you out on idling your car for ten minutes in the drive through waiting to purchase overpriced coffee every morning, so please return the favor.

"If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?" -Seymour Cray

Terrible Cluster is possibly the worst example of a computing cluster imaginable.  Four Raspberry Pi Zeros each offer up their puny decade-old ARMv6 core and meager 512MB RAM for computation.  Meanwhile, a Raspberry Pi Zero W head node tries in vain to direct traffic across an inappropriately named "fabric" using USB 2.0, host a distributed filesystem, and control power to the compute nodes.  The Terrible Cluster backplane board powers and connects all five Pis together using a Cypress USB 2.0 hub and four USB power controllers.  Through hole micro USB vertical plugs allow 6mm spacing between nodes which results in a high density compact system that fits easily in the e-waste recycling bin of your local electronics retailer, under the tire of a passenger vehicle, or down the bore of an abandoned oil well.

I created Terrible Cluster to further my experience working with cluster systems and to play with strategies for cluster deployment of firmware and applications.  This project is a fantastic opportunity to strengthen the above self-delusion through accumulation of Internet Points in the form of views and skulls.


Terrible Cluster backplane v0.1 schematic PDF plot

Adobe Portable Document Format - 83.54 kB - 10/18/2017 at 02:59


Terrible Cluster backplane v0.1 Gerbers

Zip Archive - 181.35 kB - 10/18/2017 at 02:58



Terrible Cluster backplane BOM for DigiKey

ms-excel - 2.63 kB - 10/11/2017 at 16:10


  • 1 × Raspberry Pi Zero W Head node and WiFi network gateway
  • 4 × Raspberry Pi Zero Compute node, may be 1.3 or 1.2
  • 4 × Diodes Inc. AP2191DWG 1.5A USB power switch
  • 1 × Sunon fan MF40100V2-1000U-A99 Required if using case, 5V 40x40x10 fan, 7.0CFM, 20.6dBA
  • 1 × Terrible PCB See the github in the sidebar. KiCad project, pcb v0.1 Gerbers, and PDF schematic are there

View all 12 components

  • It gets better

    ajlitta day ago 0 comments

    The problems that I saw with usbboot seem to be a result of not being designed for booting multiple targets at once.  rpiboot would end up serving bootcode.bin to all of the nodes at once, then serve the complete set of files to each node one at a time until no more Broadcom ROM boot devices are found on the bus.  This would be fine, except that the Pi seems to hang after a certain amount of time after sending bootcode.bin if the transfers haven't completed.  Since the failing node seems to die in the middle of a file transfer, I suspect that it's a watchdog timer or maybe a bug in one of the binaries involved in boot (bootcode.bin or start_cd.elf).

    Whatever the root cause, it goes away as long as usbboot services only one node at a time.  I came up with a fix that prevents rpiboot from talking to any other Broadcom devices in USB boot mode until it has finished booting the current device.  Once it sends bootcode.bin successfully to one device, it will ignore other devices when scanning for the second stage boot device until it has completed serving files to the current device.  A timeout prevents it from hanging indefinitely in the case where the current device fails to re-enumerate after bootcode.bin is sent.

    I think I have it working reliably now, but it will take some overnight testing to prove it works.

    A better solution, perhaps for the future, would be to make usbboot multithreaded, spawning a handler thread for each ROM boot target.  This should be straightforward since the USB IDs are different for a Pi waiting for bootcode.bin (2763) and one that is re-enumerated after bootcode.bin executes (2764).  This should also speed up the boot process.

  • Terribly unreliable

    ajlitt3 days ago 0 comments

    One problem that's plagued the project is the USB boot process.  The fourth node almost always fails to boot on the first try.

    Terrible Cluster relies on the rpiboot utility from the Raspberry Pi Foundation to serve the bootloader and kernel to each of the compute nodes.  rpiboot first watches for a USB device to be plugged in matching a Zero in USB device boot mode.  It then sends down the first stage bootloader "bootcode.bin".  The first stage begins executing, recognizes that it was booted from USB, and the reinitializes the USB controller in device mode.  rpiboot notices that the device has re-enumerated under a different device ID, then it enters a USB fileserver mode.

    At this point, bootcode.bin goes through the same process of loading executables and config files as when booting from an SD card: start_cd.elf, config.txt, kernel.img, etc.  But instead of fetching the files from SD, it requests them from the USB host.  rpiboot sits in a loop waiting for file requests and sending files to the device until it receives a message saying that the device is done, or a transaction with the device fails.

    This works fine for me when I'm booting one Pi at a time.  However, when I am booting all four Pi Zero nodes at once it often fails when sending the kernel to the fourth node that it boots.  rpiboot does not operate sequentially, instead sending bootcode.bin to first USB device with a matching bootloader VEN/DEV.  It is always the fourth one that fails, and it does not appear to favor a particular slot.  Once a node finishes loading all of the required files over USB, it boots reliably.  So this has everything to do with the USB boot process, and not the OS.

    If I can't trust rpiboot to sit in the background and serve files to booting nodes, then this isn't going to be a useful system for learning about software deployment.  Sounds like a good debugging project for the weekend...

  • Many OpenSCAD lines later...

    ajlitt5 days ago 0 comments

  • Hot mess

    ajlitt6 days ago 0 comments

    After a truly terrible week of meatspace problems last week, I'm back.

    I've been working on and off on a 3D printed case for the cluster.  The case doesn't need to be beautiful, but it does need to protect the cluster and restrain the Zeros so they don't flop around on the backplane's USB headers.

    One problem though: the HPL runs from earlier show that the CPUs can reach over 70 degrees under load in ambient air.  In an enclosure it's going to be much higher even with vents for convective airflow, and PLA plastic starts getting soft around 65 degrees...

    Thus a fan is going into the case somehow.

    Enjoy this pic of a test fit print while I figure this out:

  • Less terrible

    ajlitt10/04/2017 at 04:07 2 comments

    Although performance is not the goal here, I wasn't happy that the cluster wasn't benching anywhere near what I expected with HPL.  After some head scratching, I found out that the math library that I used to build the benchmark (libatlas) is built for soft-float in the RPi repos.

    I rebuilt HPL with the libopenblas math library, added the head node into the pool, and hooked up my bench supply so I can use its current meter.

    Now the terrible cluster does a max of 1.281 GFLOPS, and drew an average of 4.962W over the run.  That means it's only 72 million times slower than the fastest computer on the June '17 Top500, and at an efficiency of .258 GFLOPS/W is 4.9 times more efficent than the least efficient computer in the same list.

    (corrected with a slightly higher score after retesting 10/5/17)

  • Terrible metrics

    ajlitt10/02/2017 at 21:46 0 comments

    Following instructions found here, I ran the HPL benchmark on the four compute nodes of the cluster.  On the first try, I'm getting 390MFLOPS.

    That's 300 million times slower than the fastest ranked supercomputer as of June 2017.

    However, it's at worst only 40% less efficient* than the least power efficient computer on the same list, so that's nice I guess.

    *Didn't measure average power during the run, but it does have a 5V 2A power supply and isn't hitting the limits.  So I'm assuming 10W running full out.

  • Clusterstuck

    ajlitt09/28/2017 at 02:42 4 comments

    I spent the last couple of weeks trying to figure out the best way to deploy an OS to the nodes over USB.  I spent a few late nights trying to roll my own minimal Raspbian with debootstrap, and a few more scratching my head over how to use the USB boot and an initramfs to write the SD card on first boot or when directed to reformat and reinstall.  And I was hesitant to write anything to automate any of this, since I have my heart set on using Ansible for deployment and I'm still an Ansible noob.  I was busy yak shaving and yet I still didn't have a working way to copy an OS out to all the nodes over USB.

    And then I remembered what I named this project.

    So I went for the easy way out.  Stick with the stock Raspbian Lite image.  Modify the image so that it doesn't boot over SD and falls back on USB.  Use the mass storage mode in rpiboot to write the Raspbian SD image to each node.  Use rpiboot to serve different cmdline.txt bootfiles based on the USB hub port so that they each get their own unique USB networking MAC address.  And use shell scripts for image generation and SD writing instead of making this another Ansible lesson.  None of this is how I'd imagined it working, but at least it's working now.  Later I can move the process to Ansible and different OS images and deployment schemes.

    Three evenings later and the cluster can now write a Raspbian .img to all four nodes very slowly (30 minutes or so for all 4), boot them very slowly with a unique MAC and IP (about 5 minutes for all to come up), and take remote SSH logins from the host Pi.

    It's hard (and boring) to show any of this in action, so here's a session showing a network between the head node and all compute nodes at once:

    See?  The Terrible Cluster lives up to its name.

  • Boring bring-up pt. 2

    ajlitt09/17/2017 at 05:37 0 comments

    I soldered the rest of the board. Realized I had ordered the wrong part for the USB power connector and bodged it on anyway.  I'll update on functionality in a few days.

    But for now, enjoy some photos of the assembled board and 5 Pi Zeros:

  • Boring bring-up pt. 1

    ajlitt09/14/2017 at 05:59 0 comments

      The boards came in today, so naturally I had to get soldering despite being tired from working late last night.

      I populated everything but the USB power jack and the four downstream node USB plugs.  I didn't want to waste the connectors until I checked out the upstream end of the hub.

      I first smoke tested the board with my bench PSU and checked that the oscillator was doing its thing.  Once satisfied that I didn't have any surprise dead shorts, I hooked it to my PC through a micro USB jack to USB-A plug cable going to an intermediate sacrificial hub.  I was able to see the hub enumerate under Linux, and checked that it's reporting as having per-port power control.

      I also did a test fit of a Pi Zero W, and since I'm now confident it's not going to do any damage I powered it up.  The Pi's LED did its blinking thing as usual as Linux boots.

      Stuff I learned:

      1.  The hole dimensions for the USB vertical plug are too big to fit snugly.  I had to "justify" the upstream plug with one edge of the board.  I'll need to remember to align the other four the same way to keep the Zeros spaced uniformly.
      2. The Cypress hub IC shuts off the 12MHz oscillator when nothing interesting is happening, probably to save power.  I didn't catch this detail in the datasheet.  I spent a good half hour wondering why I'd see a fleeting 12MHz on the scope on power-on and nothing afterwards.  I suspect it will stay on once I get downstream devices connected.
      3. My thermal reliefs aren't that relieving.  I soldered in one of the electrolytics backwards, and it was a pain to desolder and clean the hole on the grounded leg.  I should have used thinner spokes on the reliefs, and made sure that there was no additional ground traces hiding under the plane fill.  It would also help if I replaced the solder sucker I broke a few years ago.
      4. Just because silkscreen art looks good in the KiCAD 3d render doesn't mean it will look the same on a finished board.  For grins I converted a photo of a picture one of my kids drew in school to a KiCAD symbol.  What was supposed to be a skull looks more like an upside down diseased pear.  Elecrow and other PCB manufacturers have a resolution limit to their silkscreen.

      Next I need to get the rest of the connectors in, test downstream power control, make up a test cable for the downstream ports (more later), and maybe plug in some more Zeros.  But that will have to wait for the weekend.

  • The sad story so far

    ajlitt09/05/2017 at 16:04 0 comments

    Last week I submitted the Terrible Cluster backplane PCB to Elecrow for manufacturing, and this weekend received notification that it has shipped.  Elecrow is nice enough to take a photo of the boards before shipping, and I can see that the plated slots for the microUSB plugs and the power jack were done correctly.  The graphic on the back, a skull my son drew last year, doesn't look so hot.  But I'm not losing any sleep over that.

    I still haven't ordered parts.  I have a BOM on DigiKey that's ready to go once I see the boards make it through customs.  I'm guessing it's a couple of weeks before I can get down to soldering.

    Meanwhile, let me catch you up.

    A few weeks ago at work I had my first experience using Ansible.  I needed to automatically build firmware for a legacy product that has very specific host requirements.  At the suggestion of a coworker, I used Ansible and Vagrant to assemble VMs with the right build environment and see the build through to completion.  While that was fun, it didn't give me an opportunity to use Ansible for parallel deployment.  I had a pile of Raspberry Pi Zeros, an interest in HPC, and an itch to make another PCB.  And so I decided to make a simple cluster.

    I first did a mock-up using a Pi3 and three Pi Zeros connected using USB device mode to gauge network performance.  I lost the numbers as they were unimpressive, but with all Zeros doing bidirectional transfers the upstream perfomance was in the 10Mb/s range and downstream was around 80Mb/s.  That's going to drag down any tightly coupled compute jobs, but since I plan to use it for playing with deployment and management I think it will be fine.

    I then looked at packaging.  I ended up choosing a through-hole soldered USB micro vertical plug from Hirose rather than the "dock" SMT one used by other similar projects so that I could fit the Pis closer together.  The SMT pins on the dock connector live on the long edge of the connector, so hand soldering would be near impossible unless I spaced them 20mm or so apart.  Cost is comparable, and the through hole is narrower which gives me more board space to work with.  For some reason, this connector and others like it require a board that's under 1mm thick.  Fortunately Elecrow can do 0.8mm boards.  I will have to take board flex into account when I make a case for this since 0.8mm could flex too easily under the strain of the vertically mounted Pi Zeros.

    I ended up laying out a board with the Cypress CY7C65632 4 port USB 2.0 high speed hub controller.  I chose this part for its on chip 3.3V regulator and the ability to configure operating modes without an external EEPROM.  I added an AP2191DWG USB power controller and a big 220uF cap to each downstream port so that the head node can control power for each port.  Each power controller is driven by the hub, and the overcurrent signals are fed back to the hub to handle any unpleasantness.  The AP2191 can handle 1.5A per port, and I don't expect any of the nodes to go above 0.7A.

    I strayed pretty far from Cypress's design guide, using a two layer board instead of four, and putting the smaller decoupling caps around the periphery of the hub chip instead on on the back side.  I think I did an ok job on trying to keep loops small for power pins and maintain USB differential impedance, so I'm hoping for the best.


    • 3D printed enclosure with strain relief for the backplane
    • Build and bringup v0.1 backplane
    • Shell scripts for USB port status monitoring and power control
    • Set up head node to USB boot the compute nodes
    • IP assignment based on USB port

View all 10 project logs

  • 1
    Get a board

    Order the PCB from the KiCad project from your board house of choice.  The board must be 0.8mm thick.  Standard 1.6mm is too thick to fit the microUSB A plugs.  I was able to get 5 boards from Elecrow for under $10USD shipped in a little over two weeks.

  • 2
    Get some parts

    Use the BOM in the "Files" section in this project to order parts.

    The BOM is a CSV direct from DigiKey and should import through their "Upload to Cart" thingy.  You might want to tweak the quantities since some of the discretes and the power switches are significantly cheaper if you go up to 10x or 100x.  Worst-case cost for parts to build a single backplane is about $16USD.

  • 3
    Solder all the things

    Solder the board according to the KiCad design.  Start with the discretes and ICs, then the vertical USB A plugs and through hole caps, then the microUSB B.

    Be very careful with the vertical USB A plugs.  Flux the pins and the pads on the solder side of the board first.  Then once you fit each plug, force it to one side of the footprint to align it before tacking it down (first board rev only, where the holes are just a little too big for the part used).  Make sure to heat each pad thoroughly, since I've had a few cold solder joints that weren't readily obvious.

    Also, the microUSB B jack in the BOM doesn't fit the footprint on the board correctly.  I had to bend up the through hole stakes at the front of the connector and apply much solder and flux to get it to sit flush.  Someday either I'll find the right part, or update the layout.  Someday.

View all 7 instructions

Enjoy this project?



ia wrote 12 hours ago point

in my opinion transfor this to fpga glue raspberry pi machine and create one computer similar epiphany


make this completly offgrid

  Are you sure? yes | no

Laura Farrell wrote 5 days ago point

Thank you for an enjoyable description, it is, at very least, a possible salutary lesson for many years of my stakeholders, who attempt to do similar things with real world hardware and software, oblivious to any suggestion that ignoring "best practice" might in any way end up with substandard, lonely, misery-making applications that nobody wants to use.  A special mention for the large retailer whose insistence on spending 5 figure sums on unusable, unsupported and useless hardware persisted (they were also taking orders from retail customers as recently as 2012 via.....dial up modems).

  Are you sure? yes | no

KMP.digtal wrote 10/12/2017 at 15:08 point


  Are you sure? yes | no

Blecky wrote 10/05/2017 at 00:21 point

This is a truly terrible project :D

  Are you sure? yes | no

ajlitt wrote 10/05/2017 at 01:49 point

Thank you!

  Are you sure? yes | no

Owen Trueblood wrote 09/06/2017 at 17:24 point

This project looks like fun.

How'd you make that nice 3D model of the PCB assembly?

  Are you sure? yes | no

ajlitt wrote 09/06/2017 at 17:30 point

I exported the board from KiCAD as VRML, then used Meshlab to turn it into STL.  I then wrote some OpenSCAD that uses the backplane STL and a Pi Zero model STL from Thingiverse to make the mockup.  The OpenSCAD and link to the Pi model are in the github in the sidebar.

The alignment of the USB connectors on the backplane and Zeros is eyeballed, so it's likely that the boards aren't aligned right.  It should be enough to make a first pass at an enclosure while I wait for boards.

  Are you sure? yes | no

Owen Trueblood wrote 09/07/2017 at 01:50 point

I've played with the 3D export feature of KiCAD but got stuck trying to use the VRML output. Converting with MeshLab is a useful tip, I'll have to give it a try. Thanks for the detailed answer!

  Are you sure? yes | no

Peabody1929 wrote 09/05/2017 at 16:07 point

I have a Pi 3 with a Cluster Hat and four Pi Zero's.  It's main purpose is to look good.  That can be said about many things in today's world.

  Are you sure? yes | no

ajlitt wrote 09/05/2017 at 21:35 point

The Cluster Hat partially inspired this project, particularly to improve on a few things like cost and size.  At some point I'll have a small 3D printed case for the system to make it a little prettier.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates