Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Pi-Powered Plan 9 Cluster

rs-online.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: A Pi-Powered Plan 9 Cluster

#31

Post by MisterTea »

pjmlp wrote: post #23
arghwhat wrote: post #6

Earlier quoted context omitted.

On plan9, all your services are file based. The difference between a cluster and a standalone setup is just whether you mount local instances of a service, or remote instances. For a cluster, you'll usually have a cwfs/hjfs (persistent storage) server, a faktotum (auth) server, and one or more CPU servers, and possibly a terminal machine. You can then freely use or connect to CPU servers. As everything is shared, and…

> everything will feel local. Not in what concerns graphics rendering performance.

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.

Re: A Pi-Powered Plan 9 Cluster

#35

Post by rwmj »

dsr_ wrote: post #34
charlieo88 wrote: post #33

Something that always bothers me about these Pi clusters is the Ethernet cable lengths. Isn't there a minimum length?

10cm for 1000BASE-CX, nothing prior specified a minimum length.

That's really interesting - do you know why there is a minimum?

Maximum lengths are easy to understand because of voltage drops, interference and impedance over long distances. And of course in the old CSMA/CD days multiple senders couldn't be separated by too large a distance.

Re: A Pi-Powered Plan 9 Cluster

#36

Post by MisterTea »

rwmj wrote: post #35
dsr_ wrote: post #34

Earlier quoted context omitted.

10cm for 1000BASE-CX, nothing prior specified a minimum length.

That's really interesting - do you know why there is a minimum? Maximum lengths are easy to understand because of voltage drops, interference and impedance over long distances. And of course in the old CSMA/CD days multiple senders couldn't be separated by too large a distance.

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

Re: A Pi-Powered Plan 9 Cluster

#37

Post by arghwhat »

MisterTea wrote: post #31
pjmlp wrote: post #23

Earlier quoted context omitted.

> everything will feel local. Not in what concerns graphics rendering performance.

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 a…

> With 9p, for every T message there's an R message that is waited on before the next T is sent.

This is entirely false.

The 9P protocol is asynchronous, can handle up to 16k outstanding requests, supports out-of-order responses, and includes support for arbitrary request cancellation,

The only thing thing that blocks to wait for an R message are blocking syscalls, but that doesn't stop other processes from sending further T messages.

Re: A Pi-Powered Plan 9 Cluster

#38

Post by ClumsyPilot »

bullen wrote: post #29
ClumsyPilot wrote: post #13

Earlier quoted context omitted.

I second this - the PI's are great for hacking and hardware, but obsession with PI for compute does not make sence. Any used PC/NUC/Intel Atom board is much, much faster and some cost around the same.

They are much faster because they draw more energy. The Raspberry 4 at 1 Gflops/watt is a better option if you want to power the thing with lead acid batteries as backup power for more than 24 hours. Also Raspberry 4 can be cooled passively with a smaller heatsink so the total size and weight is less.

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.

Re: A Pi-Powered Plan 9 Cluster

#39

Post by arghwhat »

pjmlp wrote: post #23
arghwhat wrote: post #6

Earlier quoted context omitted.

On plan9, all your services are file based. The difference between a cluster and a standalone setup is just whether you mount local instances of a service, or remote instances. For a cluster, you'll usually have a cwfs/hjfs (persistent storage) server, a faktotum (auth) server, and one or more CPU servers, and possibly a terminal machine. You can then freely use or connect to CPU servers. As everything is shared, and…

> everything will feel local. Not in what concerns graphics rendering performance.

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.

Re: A Pi-Powered Plan 9 Cluster

#40

Post by zepto »

ordu wrote: post #20

> The project provided an excuse to make use of a Vortex Core 47-key keyboard, which together with a mini white HDMI monitor, provided a particularly compact and suitably futuristic feeling setup. As for me this keyboard doesn't seem futuristic at all. It reminds me of the first computer I experienced in my life.[1] I mean, it is lovely keyboard, I really like it. Just "futuristic" is a strange way to describe it. It…

Maybe ‘retro-futuristic’ is a better term.
Post reply on HN