101–106 of 106 posts
How does the Pi communicate with the Mini? Software stack? Zero details and useful information in this post.
You might want to look at Asahi Linux's Central Scrutinizer for some insights on the fancier stuff that can be done over the USB-C port.
I was part of the team that built this project at Scaleway, ask me anything
I was interested in provisioning one of these a few months back through Scaleway, but couldn't navigate their sign-up process without it dumping me back to the start everytime. Nor did I receive a reply when I e-mailed their support e-mail. I don't know if that's changed (they had odd pricing too, like Startup vs. Business, of which the difference wasn't clear), but aware. I hope someone has more success than I did.
Unlike the old rack mount options for the trashcan Mac Pro units (eg https://photos.imgix.com/racking-mac-pros ), it doesn't seem like much thought has been given here to a front-to-back airflow. I'm also surprised they're touting the density of this solution— seems like the obvious thing would be to put the Minis on their sides. A 4U chassis has 17.5cm vertical space in it, and a Mac Mini is 17cm wide. With the Mini…
> Each rack can hold up to 96 Mac minis, Sounds like 2 per 1U to me. I think it's power efficiency that limits filling a rack with typical 1U servers in most plans. The power efficiency here is probably not really impressive enough given so many power units, etc.
I'm pretty sure the drawers are 2U, but given that I don't know how they would get 96 nodes in a standard 42U rack.
Earlier quoted context omitted.
> not sure why the attach rpi for every mac mini, wouldn't it be cheaper to have one rpi and 9 mac minis connectd to 10 port switch? Simple... they're (likely) running something on the Raspberry Pi's that sets them up as USB gadgets, aka the Mac Mini "sees" a virtual keyboard and mouse. That's enough to manage remote provisioning. To replicate that they'd need a KVM switch which doesn't have some weird edge case in h…
That's exactly the purpose of the raspberry they setup in this image
>/sys/power/s_stats is peripheral in terms of antico grego and a shallow-clientx .async language in thread_entry, arg
not sure why the attach rpi for every mac mini, wouldn't it be cheaper to have one rpi and 9 mac minis connectd to 10 port switch? I also wished one day to make cluster out of Apple TVs - they are very cheap (~150usd for version with ethernet) and most likely the new upcoming version will have more powerful A-series apple sillicon. I guess tvOS is just very restricted.
They’re connected to a single USB-C cable. For many technical reasons you can’t have a simple kvm which switches inputs. You’ll need to continuously power all 9 minis some way. All nine USB-C cables will need a continuous, active connection. To do this, you will need a smart controller that switches which port it’s talking to. Or you can stick a relatively cheap device on every mini and and connect it to the network.…
Is video forwarding part of the product offering, or simply considered required for management functions?
Either way, I probably agree that a raspi per unit probably makes sense at a scale of a few dozen racks, but it would be interesting to do the math on when it would be price-efficient to have a 1:n management node scheme. I don't imagine there are many USB-C hubs that support being display sinks on the downstream ports (if that's even possible at all) but perhaps you could use an FPGA to synthesize a small ARM core with a bunch of native USB-C interfaces capable of doing it?