When you drop a second Arduino onto the SimDuino canvas, something subtle happens that doesn't happen with any other component: you now have two independent computers in the same room. Two CPUs. Two clocks. Two notions of "now." The visible blink rate of each LED hides a deeper truth about how embedded systems work.
Each chip has its own pulse
On the real Uno, a small quartz crystal next to the ATmega328P vibrates at 16 million times per second. That vibration drives the chip's clock distributor, which drives every other piece of timing inside — instruction fetch, timer compare matches, the millisecond counter that millis() reads. Even two crystals stamped from the same factory drift; they're matched to about ±50 parts per million. Two boards running identical blink sketches will fall a few seconds out of sync over a day.
The simulator models the independence honestly: each AVRRunner has its own cpu.cycles counter, its own register state, its own program memory. Drop two Unos with different sketches — like the paired demo's 250 ms vs. 750 ms blinks — and the LEDs run unrelated rhythms because the programs themselves are different. The one idealization to know about: in the simulator both runners share a wall clock (performance.now()), so two identical sketches would blink in near-perfect sync. Real hardware doesn't share a wall clock — each crystal has its own ±50 ppm tolerance, and over hours two boards running the same sketch will accumulate seconds of drift between them.
Concurrency without coordination
Two Unos doing things independently is the simplest possible distributed system. Software people call this concurrency: multiple actors making progress at the same time, with no shared state and no synchronisation. The two boards are the actors. The canvas is the shared physical world, but nothing in it forces them to agree on anything.
This is exactly the model that real embedded fleets use. A modern car has 50-150 computers, each running its own program against its own clock. The brake controller doesn't ask the entertainment system what time it is. They coordinate over a shared bus only when they have to. That's expensive to design — but it's what makes the system fault-tolerant. One chip dying doesn't kill the rest.
The blink demo as a teaching primitive
Two LEDs blinking at unrelated rates looks trivial. It's the cleanest possible illustration of the fact that your program does not own the clock. Once you internalise that, almost every embedded bug becomes diagnosable: timing assumptions you didn't realise you were making, race conditions between two devices both racing to be first, schedulers that promise more than the hardware can deliver. Start here.