RAIN Mark II Personal Supercomputer

High-Performance Computing for Everyone

Similar projects worth following
RAIN is an open-source project to design and build open, efficient, and accessible supercomputers. RAIN's mission is to make supercomputing accessible to a wider and more diverse audience and encourage the development of new, innovating and compelling high-performance applications.This project is focused on the RAIN Mark II Personal Supercomputer. The goal of this phase of the RAIN project is to create a small, inexpensive computer with the same architecture as a large scale cluster to facilitate learning and the development of new high-performance applications while making owning and operating the system accessible to a wide-range of programmers, designers and users.Completion of the Mark II PSC will provide a platform for research & development on the next phase of the project to make the design even more open (switch from ARM to RISC-V) and more powerful.

Up until now I've been documenting my work on RAIN (formerly known as *Raiden*) on my blog at  This includes information about the previous phase of the project (Mark I) and longer discussions of the philosophy behind the work (and why I think it matters).

Here I'm going to focus on documenting ongoing work on a specific machine, the RAIN Mark II Personal Supercomputer. 

Mark II is an 8-node ARM computing cluster using a Gigabit Ethernet interconnect.  It utilizes a combination of PINE64 SOPINE modules and PINE A64 single-board computer to create a distributed-memory supercomputer with up to 32 ARM cores, 16 vector/GPU cores and 16 GB of memory in a small, clean (and I think, beautiful), easy-to-use package.

In addition to the hardware, the RAIN project involves making the creation of new high-performance applications approachable by people with little or no experience with supercomputers.  My goal is to do for supercomputers what the personal computer did for mainframes.  This means more than putting the box on someones desk, it also means giving them tools to use it the way they want to.

The design has gone through many revisions and I've recently abandoned some of my own work in favor of using the PINE64 Clusterboard.  I didn't take this change lightly as my designs for assembling arrays of PINE A64 boards is more flexible and scalable than the Clusterboard, but the board is just so perfectly suited for the Mark II's design and meets the needs of the goals I have for Mark II with almost no compromise, so it's the obvious choice.

This means I can get the machine operational faster, and design a machine that is much easier for others to reproduce (sticking to off-the-shelf components is one of the design goals for Mark II).  All of this means I can turn my attention to the software side of the system sooner and I think that's where I have the most value to provide anyway.


Magnetic mount for A64 board (rear end)

sla - 266.81 kB - 03/15/2018 at 14:45



Magnetic mount for A64 board (face end)

sla - 280.46 kB - 03/15/2018 at 14:43



Magnetic mount for Clusterboard (4 needed)

sla - 297.94 kB - 03/15/2018 at 14:43


Mark II Front Panel v3.svg

Front panel version 3

svg+xml - 28.87 kB - 03/15/2018 at 14:42


View all 19 components

  • On the road

    jason.gullickson5 days ago 0 comments

    Just a quick note to say that it will probably be a week or so before I post another update on the project.  I’m currently on a road trip across the western U.S. and won’t be back in the lab until around 04/01.

    When I do get back, I’ll probably work on moving the panel driver from the breadboard to something that can be installed in the chassis.

    Also I see some of you have left comments and even expressed interest in joining the project.  I will get back to all of you as soon as I’m back from the trip.

    Thanks again for the interest and support!

  • Arms & Legs

    jason.gullickson03/16/2018 at 01:24 0 comments

    Technically, the Clusterboard fits inside the case I’ve been designing around, but it doesn’t fit inside the “endcaps” so it can’t be mounted directly to the steel of the case using the mounting holes on the board.


    To address this, I sketched-up some adapters to “relocate” the mount points somewhere more appropriate. Since I’m still not 100% sure where everything will belong in the final configuration of the chassis, I came up with a more flexible way to mount the board: magnets!



    I also need to mount a single PINE A64 board to serve as the “front-end node” so I whipped-up a couple of magnetic mounts for this board as well.

    I wasn’t able to find appropriate magnets locally so I had to wait for some to arrive from The Internet. In the meantime I switched-gears and worked on writing a little software to drive the panel’s display.

    This has never happened before…

    When the magnets arrived I was stunned to see they fit perfectly on the first try. However I didn’t have any glue on-hand that was right for the job. Since I was tired of waiting I thought about how I might modify the mounts to eliminate the need for glue. This turned-out to be easier than expected and after two iterations I had working, glueless mounting brackets.



    All-in-all they work pretty well.  There is some alignment problem keeping all four feet on the Clusterboard from engaging the inside of the case completely, but I think this will be strong enough to safely move on to the next step: stuffing everything inside the box.




    The idea of modifying a part just because you don’t want to run out and buy some glue would seem ridiculous before I had a 3d printer but now it’s easier and faster to just “run-off a new part”. The result is not only faster, but it’s also a better part. This is one of the things I love about 3d printing, the ability to iterate at a pace similar to writing software and letting the robots do the work.


  • Ambitions, plans and kits?

    jason.gullickson03/15/2018 at 15:10 0 comments

    It's very exciting to see other people interested in this project.  Thank-you for your feedback and encouragement!

    In addition to releasing my work as open-source (so others can reproduce the machine), I'm considering developing kits (and perhaps a small number of assembled systems) once I have a design that is stable, reliable and repeatable.

    I haven't gone too far down that road yet because there's still a lot to do, and I wasn't sure how many other people might be interested in owning a machine like this, but if there's interest (and I can wrangle the resources) I'll seriously consider it.

    Starting a computer company is something I've dreamed about since I was a kid banging-out BASIC on my VIC-20.  It would be kind of poetic if in doing so, I could help put other kids on the same path.

  • Front Panel Software v1.0

    jason.gullickson03/14/2018 at 15:06 0 comments

    The front panel of RAIN-PSC serves three essential purposes:

    1. Show the status of each node
    2. Show the load on each node
    3. Look really cool

    The panel is actually eight individual control panels (one for each node in the cluster). Each panel consists of five LEDs and a toggle switch. The switch selects between two display modes: status and load.

    When the switch is in the status position, each LED indicates the following:

    • boot (on when the os has booted successfully)
    • network (on when the node has successfully connected to the network)
    • temp (on when the node temperature is too high to run at full-speed)
    • user 1 & user 2 (used to indicate custom status selected by the programmer)

    When the switch is in the load position, the LEDs behave as a bar-graph displaying the unix load of the node.

    To provide this display the software needs to be able to:

    • Poll the status of each monitored subsystem (os, network, etc.)
    • Read the system load
    • Read the toggle switch position
    • Turn the LEDs on and off

    When I started putting the electronics together, I used some command-line tools to interact with the LEDs and switches (I think it’s possible to write do all of the above in a shell script). In the long-run, I’ll probably write this in something faster/more efficient (Rust?) but for now, I’m going to use Python to get the hang of talking to the new hardware.

    I’m installing a few things on top of the base Armbian to make this happen:

    • python
    • python-dev
    • python-pip
    • python-smbus

    The source code for the current version of the software can be found here.

    The script can be broken-down into three primary components:

    1. Functions to gather system information
    2. Functions to read and update the front panel components
    3. A loop to periodically update the display

    Gathering system information using Python is a pretty well-worn path, so I won’t discuss that in detail here.

    Reading the position of the toggle switch and turning the LED’s on and off is done using the smbus Python package. This package interacts with the bus in much the same way as the command-line i2c tools.

    The hardest part of this for me is coming up with the best way to translate between the binary representation (the pins themselves), the boolean/decimal values I’m used to working with and the hexadecimal values that glue the two together. What I settled on was using hexadecimal internally to the functions which generate the display (display_status(), display_load()) and boolean/decimal values everywhere else. At some point I’ll abstract all this away into a library or a module, but since I don’t plan on using Python for this long-term I’ll probably hold-off on that for now.

    Remote hardware debugging thanks to Octoprint’s webcam…

    Finally, the main loop simply loops forever, calling toggle_on() to determine the position of the status/load switch and then calling display_load() or display_status() accordingly. Once the display is updated the loop sleep()s for one second and then starts over. In its final form this will need to update the panel much faster than once-per-second (potentially leveraging interrupts as well), but for this version this is probably fast enough.


  • Why Personal Supercomputers?

    jason.gullickson03/12/2018 at 18:54 0 comments

    If you're asking yourself "what's the point in building another little ARM cluster?" I can totally relate.  Answering questions like that is actually what motivated me to begin this project.  I've thought about this a lot and written a bit about it here:

    This post is a little behind the current state of the project and I've refined my ideas a bit since then, but I think it does a good job of explaining my motivation behind creating the RAIN project and the multiple vectors I'm exploring.

View all 5 project logs

Enjoy this project?



David H Haffner Sr wrote 5 days ago point

I love this project and I could have used this thing about 20 years ago :)

  Are you sure? yes | no

ajlitt wrote 03/15/2018 at 16:24 point

I really like the idea of making esoteric hardware public!

There are already HPC job schedulers that do what you describe, but typically manage one cluster / HPC system at a time.  One example that's used widely and is GPL'd is SLURM: .  I don't know if it would be possible to extend it to do what you're looking for, but it would be neat to try to make it work on small embedded clusters like yours.

  Are you sure? yes | no

riktw wrote 03/15/2018 at 08:43 point

Very nice looking project, I like the oldschool look case with blinkenlights. Is this type of case still available somewhere?

  Are you sure? yes | no

jason.gullickson wrote 03/15/2018 at 14:22 point


It took me awhile to find that case, but once I knew what to call it I found several on Ebay, here's an example:

It's not *exactly* what I wanted, I really wish it had a removable top (it would make the machine a lot easier to work on).  I have found some with removable tops but they are considerably bigger (and more expensive) and they don't seem to capture the form of the old machines as well.

  Are you sure? yes | no

Mark Rehorst wrote 03/14/2018 at 16:50 point

This is a very interesting project.  How will you keep the coin miners and DDoS elements out of the network of personal supercomputers, or is that sort of thing the purpose of setting up the network?

  Are you sure? yes | no

jason.gullickson wrote 03/14/2018 at 19:13 point

At the moment I don't intend to prevent any specific use case (even boring ones :) )

That said, I'm working on ways to make this network less valuable for these types of applications.  For example, one thing I'm considering is that the way you earn "credit" to use the network is by allowing other's jobs to run on your system when it's idle.  This puts a natural ceiling on the amount of network power available to any individual user. 

Something like this doesn't make abusing this network *impossible*, but it makes it less attractive than using say, a botnet of pwned IoT devices...

You bring up a good point though and it's something I think about as I noodle on how the global network might work.  That's part of the reason I'm focusing on a stand-alone system first and taking my time before introducing the increased risks of distributed systems.

  Are you sure? yes | no

davedarko wrote 03/12/2018 at 20:00 point

very clean case design, I like that a lot!

  Are you sure? yes | no

jason.gullickson wrote 03/12/2018 at 20:55 point

Thanks!  I had originally planned to use an opaque panel on the final design (this being just a prototype), but everyone seems to like the transparent one.  We'll see if I can keep it tidy looking once as more of the electronics fall into place...

  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