Live data from Hacker News

Build your own bare-metal ARM cluster

blog.alexellis.io

11–20 of 38 posts

Re: Build your own bare-metal ARM cluster

#12
It's too bad that OpenMosix withered on the vine. Back when it was a thing, I found it really handy to fire up clusterKNOPPIX on a bunch of idle PCs for large compile jobs.

I guess with today's multi-core CPUs, it wasn't thought to be worthwhile, but it could still come in handy for resource-constrained systems like the Pi.

Re: Build your own bare-metal ARM cluster

#14
Only practical reason I can recommend this would be either you'd like to experiment with cluster tools or connection outages (e.g. seeing how system tolerates when you unplug an ethernet cable).

Also, while OpenStack/K8 could seem to be a reason having something like this, I discovered it is a bit overkill for home needs. For that part, I'd go for a small server instead and manage it manually (no shame).

Re: Build your own bare-metal ARM cluster

#15
post #13

Given what the article says about k8s not working so well in the RPi's 1GB of RAM, is there another cheap ARM SOC that has more RAM available that could work similarly?

RK3328: Pine64's ROCK64 comes in 2GB and 4GB of RAM

(also the RK3399 based ROCKPro64 is even more awesome, bigger form factor, but two A72 cores for actually good performance! Oh and some other manufacturers even made RK3399 based RPi-sized boards!)

Re: Build your own bare-metal ARM cluster

#16
post #7

Note that the Raspberry Pi can boot over PXE without an SD card these days, which should make for a much more reliable setup.

I found that to be extremely unreliable, I had to reset the Pi a few times before it actually made TFTP requests.

A tiny SDcard with just U-Boot on it, configured to netboot, has been actually reliable.

Re: Build your own bare-metal ARM cluster

#17
post #7

Note that the Raspberry Pi can boot over PXE without an SD card these days, which should make for a much more reliable setup.

I found that to be extremely unreliable, I had to reset the Pi a few times before it actually made TFTP requests. A tiny SDcard with just U-Boot on it, configured to netboot, has been actually reliable.

Unless you are running 3B+ pis, the firmware code for pxe booting has several bugs. Also, Pis have issues with retransmission of DHCP requests on low end network hardware that doesn't set link up fast enough to hear the Pis intial dhcp request. Almost all of these bugs are fixed one way or another at this point though, the github issue tracker for raspberrypi/piserver and friends has lots of info.

Re: Build your own bare-metal ARM cluster

#18
post #13

Given what the article says about k8s not working so well in the RPi's 1GB of RAM, is there another cheap ARM SOC that has more RAM available that could work similarly?

RK3328: Pine64's ROCK64 comes in 2GB and 4GB of RAM (also the RK3399 based ROCKPro64 is even more awesome, bigger form factor, but two A72 cores for actually good performance! Oh and some other manufacturers even made RK3399 based RPi-sized boards!)

Cool stuff at pine64. Thanks for the tip!

Re: Build your own bare-metal ARM cluster

#19

Earlier quoted context omitted.

I found that to be extremely unreliable, I had to reset the Pi a few times before it actually made TFTP requests. A tiny SDcard with just U-Boot on it, configured to netboot, has been actually reliable.

Unless you are running 3B+ pis, the firmware code for pxe booting has several bugs. Also, Pis have issues with retransmission of DHCP requests on low end network hardware that doesn't set link up fast enough to hear the Pis intial dhcp request. Almost all of these bugs are fixed one way or another at this point though, the github issue tracker for raspberrypi/piserver and friends has lots of info.

Yeah, (a while ago) I also tried just having the firmware update on the SD card, it was a bit more reliable but still far from 100%…

Re: Build your own bare-metal ARM cluster

#20
One caveat when deciding on an ARM platform to adopt is the fact that someone needs to maintain a custom Linux branch for each individual SoC configuration.

That means you'll want to choose a platform that's very well supported by its parent company if you don't want to get stuck on an obsolete kernel in a year.

Hardkernel, who design and produce popular ARM SoCs, chose to produce x86 based platforms in the future for this reason.

Post reply on HN