I made a small SAN, just for learning. Four pi4's serving two USB-SATA disks each via iSCSI to my NAS, which mounts them as a ZFS pool. The pi4's are connected to a switch with a 10G link to the NAS.

Again, mainly just for fun and experience.

signal reflection most likely. https://en.wikipedia.org/wiki/Signal_reflection

PI's are not really power efficient - their CPU is made on super-obsolete 40nm node. They have no sleep mode, or any low-power mode for that matter. Imagine how long a phone would last on that battery - its the same class of CPU.

An Intel compute stick or beelink mini pcs are also passively cooled and weigh no more.

Depends on the latency which is the achilles heel of 9p and plan 9 in general. With 9p, for every T message there's an R message that is waited on before the next T is sent. So if there's 100ms of latency you have to wait 100ms between EVERY 9p message. Pain and suffering. The labs people never focused on performance but actually building a clean comprehensive system with the small team they had. It was a pragmatic approach for sure and compromises were made.

Though when using local ethernet, heavy graphics isn't that bad. I can play doom over local ethernet using drawterm to a cpu server which is actually running the doom processes. Of course blowing up the game screen makes it suffer as doom doesn't use dev draw.

Another thing to realize is that plan 9 graphics are done via dev draw which is a sort of 2d graphics engine that you load text and bitmaps into then issue commands to draw and move them around on screen. So a local dev draw on the terminal only receives draw commands for the loaded resources so there is some caching and heavy lifting done at the terminal end. It's not like vnc or rdp where you are viewing a remote frame buffer.

Have you used a Plan9 UI recently?

The simple draw commands issued by Plan9 applications over /dev/draw by e.g. acme or rio shouldn't be cause for concern.

There is no accelerated graphics here, nor UIs that need it.

Nope, if you compare theoretical Gflops/watt it's probably 30%, but in practice you'll only get maybe 15%. Memory speed is the bottleneck and you cannot get around that. DDR3 had lower latency than DDR6 and only bandwidth is increasing, and you have to ask bandwidth for what?

Yeah, using Plan 9 for the graphics rendering stuff Hollywood was using Irix and NeXTSTEP for, wasn't never on the team's roadmap, specially when on Inferno the UI was based on Tk.

> Of course it does, where do you think IrisGL and Renderman were used for?

Not only are you confusing native UI stack for OS/HW capabilities, you are also seemingly confusing CPU/GPU workloads.

Nothing at all stops Renderman from running on Plan9, other than Renderman not having native Plan9 support.

Renderman does CPU ray-tracing, as ray-tracing still cannot be done in GPU (and no, RTX has no value in production quality rendering). The only GPU feature of Renderman is a post denoising filter, which will otherwise happily fall back to CPU.

> An OS architecture that doesn't do DMA for maximum hardware performance just isn't up to the game.

DMA has no effect on Renderman.

At this point, based on this history of this thread, I'll have to conclude that you have no idea what you're talking about at all.