Close

Where am I ?

A project log for Clunky McCluster

This PCB makes it practical and efficient to build a small cluster of 4 Raspberry Pi (a Quad) that can be connected to other quads.

yann-guidon-ygdesYann Guidon / YGDES 07/29/2021 at 00:027 Comments

One of the features that this project can provide (if implemented) is with helping each node find its static address.

Usually one would either use DHCP or static IPs for the Ethernet port. DHCP makes it tedious to know who is who and requires a master node to handle probing the network, while static IPs require a manual management, at least modifying each config file during the SD card duplication. Tedious.

The FPGA provides 4 ports and is intended to communicate with other quads, so each FPGA has its own address, that can be setup with jumpers/DIL switches/hex encoding wheels/whatever. And each Pi port is static so it can have its own fixed address.

Let's say there are 4 Pi ports, so 2 hardwired bits, and the FPGA can fetch its own address from a few GPIO pins (to a 74HC165 or 4017 for example, or even charlieplexing? SPI requires 4 wires, I²C only two but is more complex). This port address can then be read/fetched from the respective Pi which will then execute the program related to its address. Let's be reasonable and say we have 6 bits for the quad address, that makes a byte for each Pi which can then configure its own static IP address. That would be the best of both worlds :-)

Another aspect is that, if several quads need to be connected, each quad must know its own address to send and receive packets. No routing is possible without addresses.

Discussions

Ken Yap wrote 07/29/2021 at 00:22 point

You could use DHCP with address reservation. All that the DHCP server needs are the MAC addresses.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 07/29/2021 at 01:55 point

OK but who could read the DHCP's table ?
It's getting a bit complex here... And ideally there would be no need of DHCP because it implies that one more node must manage the rest of the cluster. Hopefully the cluster would work without a manager node, in the beginning. In almost all my Pi installations, I use static IPs anyway, because the network is isolated.

  Are you sure? yes | no

Ken Yap wrote 07/29/2021 at 02:18 point

You could manage the mappings in any way that you like and use it to generate the DHCP config file. That's the way it's done at ISPs for example, the mappings are in a database, and that generates the DHCP config. I wouldn't really call it management, just configuration control. Once a node has received its IP address allocation it won't ask again until half the lease has expired. You could set a very long lease, some places even use periods as long as 6 months. Even a Pi can be a DHCP server, it's a light server task.

I use DHCP on my LAN because many devices don't even cater for static IP configuration and I want some devices to have chosen IP addresses so that I can easily refer to them.

Lots of online info on DHCP.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 07/29/2021 at 12:46 point

@Ken Yap
I agree on many on these things but DHCP is not a solution for the other side of the problem, which is: routing messages between Pis on the FPGA-based interco. Furthermore it is more convenient to have a 1-to-1 mapping of the nodes on both networks.

Now, something very useful will be a networked file system, such that there is no need of a managing node to probe results or upload programs manually.

  Are you sure? yes | no

Ken Yap wrote 07/29/2021 at 13:13 point

Never said it was. It's just to give an identity to each Pi based on its MAC, which is the one thing that is unique to each Pi. I was only commenting on this log, not your broader project.

Another way would be a deterministic hash from the MAC to a range of private IP addresses.  This technique is used in SSSD to map Windows user SIDs to unique Unix uids.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 07/29/2021 at 13:28 point

Hi Ken :-)

You brought up the existence of the unique MAC address, which I overlooked.

Now, one desirable feature is that if a Pi fails or a quad needs an upgrade, I can simply shutdown/unplug the Pi, put its SD card in a new Pi and plug the new one back on the same port, without caring to change any config file. Since each MAC address is associated to an individual Pi and not its position, this makes management of such a cluster harder than with a usual LAN, where a station can change location and still keeps working as ever.

For now my inventory says I can build 4 quads, with two of them "for the show" and the rest doing most of the useful work. If I design things well, I could replace some of the old slow nodes with Pi 4s later. I'd like this upgrade to be as effortless as possible :-)

  Are you sure? yes | no

Ken Yap wrote 07/29/2021 at 13:33 point

Just edit the MAC to IP mapping.

  Are you sure? yes | no