What My Thesis Assumed About Hardware

In 2021 I published a paper with my advisor at CLOSER on a tool I had built, Runlet: a cross-platform IoT tool for interactive job execution over heterogeneous devices with reliable message delivery. I wanted to start a job on one machine, watch it run on another, and answer a prompt halfway through, even when the two machines shared no operating system and the network between them was bad.

I reread it this week. Half of what I argued has held up and half has not, and the line between them is cleaner than I expected.

The machines I built it for

My test bench gives away every assumption I was making. Three single-board computers: one from 2012 with a single 700 MHz core and 512 MB of memory, one at 900 MHz with a gigabyte, and the newest at 1.4 GHz, also a gigabyte. Two laptops sat alongside them doing the managing.

That gap was my whole premise. I treated the small devices as things you send work to and read results from, because I did not think they could hold the coordination logic themselves. So I put coordination in a broker and gave each device an agent that talked to it. Every decision in the architecture follows from believing a device was too small to be trusted with much.

The demo I was proudest of was running htop on one of those boards from a laptop across the network, function keys and all, with the whole interactive session carried over a message queue instead of a shell connection.

The machines that arrived instead

A board you can buy today has four cores at 2.4 GHz and comes with up to sixteen gigabytes of memory. Against the newest device on my bench that is roughly forty times the memory, several times the throughput per core, and a move from a 32-bit instruction set to a 64-bit one.

The comparison that stings is not with the boards. It is with the laptops. The 2013 machine I used to manage the fleet had two cores at 2.6 GHz and eight gigabytes. A board costing a fraction of what that laptop did would win most of that comparison now. The thing I was managing caught up with the thing I was managing it from.

So my premise weakened. A device that runs containers, holds a real database and does inference locally does not obviously need something else deciding what it should run next. Designing this today, I would push most of the decisions out to the edge and treat the broker as a channel rather than a controller.

The part I would not change

Everything I wrote about reliability I would publish again unedited.

Devices still do not agree on how to talk to each other. The networks between them still fail in the way that actually matters, which is not slowness but disappearance. A queue that survives a node dying mid-job, and a broker that comes back from a restart still holding what it had, are worth what they were worth then.