BrickOven™ PizzaBox Hack revisited . . .

[uniserver]

Maybe you could buy this and make a 72 Ghz Intel Atom Cluster

http://www.ebay.com/itm/Bulk-Lot-of-45-HP-t5740-Thin-Client-Computer-Intel-Atom-1-6GHz-4GB-Ram-4GB-Flash-/310639718370?pt=US_Thin_Clients&hash=item485391efe2

 

[Cory5412]

Maybe you could buy this and make a 72 Ghz Intel Atom Cluster

On monitor mounts, no less.

Hackwhine! Hackwhine!

As JT mentioned, please don't do this. It literally adds nothing to the thread. Like, it contributes even less than "me too" and in general, it's not a very good schtick.

Also, as a general rule, I approve significantly of what's going to end up being 68k Mac blades.

I would approve significantly of a version of this based on Performa 630/6200/6400 boards, especially if you can figure out how to make the units share an optical drive without restarting or shutting down every system in the enclosure, and of course KVM into a well-integrated enclosure is always a plus.

Something like the tower version of this: http://www.fujitsu.com/fts/products/computing/servers/primergy/blades/bx400/ -- In fact, if you put it on castors, the whole thing becomes even better.

 

[tecneeq]

Can you run it remotely from Germany to do your compiling?

Yes, sir, i believe i can :approve: . I'll look into netbooting NetBSD on a LC475 from a floppy this weekend. Custom ROMs are fine, but maybe not really needed just yet.

It probably would be best and least intrusive to use a virtual machine to run the needed network services. What kind of VM can you run? Can you run VMWare virtual machines?

Getting the BrickOven to run stable under load (that means, providing proper networking connections, proper power supply, electromagnetic shielding, stable and plenty ram), that is the real problem. The software side could be done by every two-bit Unix admin.

 

[Trash80toHP_Mini]

Therein lies the rub. I'm not an admin of any type, by any stretch of the imagination . . .

. . . unless SneakerNet counts? :lol:

Would giving each MicroQuadra its own dedicated SCA drive help at all?

I'll look into the Quadra 630/Performa 6xx angle, that'd be really easy. I wouldn't even bother trying to make a backplane, just remove all the plastics and bolt 'em up with standoffs . . .

. . . ooooh!!!!! :O

< scampers off to play with hardware >



I can mount 'em vertically in bricks of four on the TelCo rack. Two bricks will fit under the 32" HDTV with room left over for a KM drawer.

Unfortunately the Two SIMM Slotted 640 DOS variant is in demand, those would rock, but I only have the one Q630 MoBo ATM. :-/

CS1 NICs will be difficult to source as well I think.

I've already got The OmniView Mac converter and MiniView four port PS/2 KVM, the cables for which can easily be converted to ADB. Would a "KVM'd" serial port connection be of any use?

-- Chassis would be a galvanized sheet metal enclosure behind the uprights for added cubic

-- largest cooling fan available to boost airflow on back of chassis

-- weatherstrip guide the exhaust fans, directing airflow toward auxiliary fan on backplane

-- MiniView four port PS/2 KVM with converted input connectors

-- Power Strip

Advantages:

-- retains Class A RFI shielding

-- retains UL approved packaging

-- available FDDs for boot

-- IDE a/o CD bay SCA converter options

I've got the MiniView A/B switch to gang two bricks of four Nodes each already hooked up to the Mac Converter . . .

. . . with four more 4 Port Miniview KVMs I can handle 4 Bricks/Sixteen nodes . . .

. . . and a Foundry Networks 24 port thingamajig If I decide to fill the Rack . . .

. . . to run it as a space heater for the winter months. :lol:

 

[tecneeq]

I'm not sure, but i believe that 10 MBit ethernet to a fast fileserver with large buffers and maybe even a SSD is faster than any local disk. Mind you, sustained read or write isn't important, only random access times count.

At the weekend i'll play with the software side. :approve:

 

[Trash80toHP_Mini]

Dunno about that 10bT vs. local disk angle, even at only 2-3MB/sec, direct connect local access almost has to be faster than a handshaken 10-Mb/sec. :?:

Local Disk for VM in a pinch?

Not to mention startup . . .

 

[tecneeq]

Just to let you know, you are not the first planning a 68k-mini-cluster. And i am not the first to connect the dots and think package-compile-cluster:

http://comments.gmane.org/gmane.os.netbsd.ports.mac68k/5448

Can't wait for the weekend to test some things. Haven't really played with the obscure stuff in NetBSD for years. I believe there is no easy netboot solution yet, i have to compile a special kernel. The generic kernel is 3.6 MB uncompressed, so i have to shrink it quite a bit, too. :approve:

As for disks, maybe they are a tad faster after all at random access, they are for sure at continuous transfers. This can be tested.

But the idea of not having them in the BrickOven is not without value. Imagine, no noise. If you assume a BrickOven with 7 nodes, you would have about 70 watts peak power you would have to provide on top. Not to speak of heat dissipation and maintenance.

 

[CelGen]

Why not just use remote desktop software to access each system? If you run MacOS you got Apple Remote Access and if you do run a BSD you got pretty much every other method to access the system. A KVM arrangement will give you a stupid large mess of cables. I still do not see why you need a CD drive for each. If you're networked you only need to mount a remote volume and pull data from there. Running SCA drives will also require another layer for each two slices you run. You build a disk image on one system and clone it to multiple CF cards.

 

[Trash80toHP_Mini]

A KVM arrangement will give you a stupid large mess of cables.

I thought stupid large messes of cables were teh point of having a rack! :lol:
BrickOven2™ is meant for playing with each level independently over KVM. Having LC, LCII, LCIII, and three LC475/Q605 layers to make up the six CPU PDS Expansion Card PlayStation, so it needs KVM.

The original BrickOven™ was a six level 68040 hack looking for an application. It was a design exercise intended to hoover up some of the large excess of MicroQuadra™ boards in Aus.

The RackOven™ is just a day old design exercise. It's more feasible to run 1 to 6 bricks of four Q630 nodes each in a TelCo Rack than to build even one BrickOven™ if you really think about it. As far as CDs go, only one person mentioned using a single one for the array. I think using the CD Bay in each of the 6xx boxen for an adapted, fast access U160 or SCA Drive makes the most sense. No need for NetBooting or startup floppies and plenty of space for VM/scratch disk/whatever.

I'm not a UNIX geek or Network admin of any sort, I HATE networking, but KVMs and SneakerNet I've got down pat. )

 

[onlyonemac]

Just as long as you don't destroy (modifiy) the case then I'm OK.

 

[Trash80toHP_Mini]

Your OKness is the least of concerns. :lol:

One nice thing about going with the 6xx version is that the case parts are pretty much flat slabs for storage, as opposed to the complex, voluminous forms of the 'zaBoxen.

I got a kick out of knocking the LisaP graphic out in AI this morning, I think I'll do a front view of what a six brick/24 node RackOven™ might look like in my TelCo Rack. [}] ]'>

 

[tecneeq]

This whole thing really tickles my geek bone.

I sat down today to check out the source tree for NetBSD. Turns out quite a bit has changed since the old days. But i managed to crosscompile a custom kernel which compresses to about 1 mb. Now i'm looking at tricks to shave a few more kb from the kernel.

So, what would a minimal system 7 floppy cost me in terms of size? I really just need it to get starting and run the bootloader. I don't need fonts, drivers, symbols or anything at all.

 

[Trash80toHP_Mini]

Why the Floppy? :?:

3.5" SCA drives and adapters are going for peanuts lately. }

 

[tecneeq]

I believe a diskless BrickOven would perform better if files reside on a fast NFS server. Also it saves about 10 watt per node peak power need. Say you have 30 watt per node peak, with moving disk this would be 40 watt. If you use 7 nodes (wich is a perfect number for network switching reasons, i'll use it as an example) per BrickOven that would be the difference between transporting away 210 watts or 280 watts of heat.

Now, the numbers are just pulled out of my still incredibly good looking butt, but you probably get the way i think. The less hardware, the more dense the package can be packed without heat problems. Also it would be the difference between 35 kw/h and 47 kw/h for a week of serious work.

You might think that heat and energy isn't a problem. It becomes a problem when all nodes do serious work. How much energy does a floppy waste when idle?

If you want to use disks, why not, do it. But i want to research the floppy option regardless.

 

[Trash80toHP_Mini]

HRMMM???? :?: I'll have to try booting the Quadra 630 from the universal install CF cards that I use for booting/testing PMCIA PowerBooks. }

 

[tecneeq]

Right. That would beat a floppy solution. |)

 

[tecneeq]

Another option must be found. :O

A floppy holds about 1.4 mb of files. My smallest possible kernel is 930 kb compressed. I need another 100 kb for the bootloader and 550 kb for the System file (system 7 de from the install floppy). I'll also need space for the right enabler.

I'm not aware of any System 7 file that is smaller. System 6 doesn't work, i need it 32 bit safe for the bootloader.

So it seems i can not use a simple floppy (i have a bunch of factory new 2 mb floppys for IBM PS/2 50 and up, alas, there is no support in the drives or mac firmware for them).

Maybe another approach should be tested. Suppose i have a netatalk server with a share that holds the bootloader and the NetBSD kernel. All i need is a system 7 floppy that is network aware, logs in automagically, and then starts the bootloader. Piece of cake, right?

 

[Trash80toHP_Mini]

HDD, spin, baby, spin! }

 

[bbraun]

I've finally taken a look at mac68k netbsd.

Given what I've posted here, I'm 99% positive it's entirely feasible to create a MacOS-less booter for netbsd. Not that I'm volunteering for such a thing, just pointing out that it is possible. Then maybe the netbsd mac68k installation process could be a little less painful with a bootable iso or something.

A couple thoughts on how to accomplish this:

1) bootblocks with the right version let you execute arbitrary code right from the boot blocks. Best case, this would let you get away with no HFS partitions at all. Worst case, you have a MacOS-less HFS filesystem the bootloader loads from.

2) If the bootblocks approach fails, you can always fall back to creating a pseudo-System file, and the 'boot' resources will be executed by the ROM at boot. Do the booting here.

The NetBSD kernel is currently relying on the bootloader passing in a bunch of information, such as the address of the framebuffer, the amount of memory, and also relying on the ROM/MacOS's MMU setup. For instance, since NetBSD does no initialization of any mac memory controller, it is relying on RAM being contiguous and mapped at address 0 and whatever size the bootloader passed in. It would still be possible to preserve this model with MacOS-less booting, but it'd be nice to move away from that and initialize and map memory yourselves, so you can do useful things like use 128MB SIMMs on djMEMC based machines without needing custom ROMs.

Additionally, there's some pretty low hanging performance improvements (ok, not so much low hanging fruit as much as tripping over watermelons on the ground), particularly in the area of libc. You can probably get fairly substantial improvements in build times with some rather mundane changes to libc, just to improve executable launch time, reduce io and memory overhead.

Since I've finally got netbsd installed, I'll start poking around a bit more.

 

[tecneeq]

That sounds awesome and i have the feeling you know what you are talking about.

I couldn't test the floppy/netatalk boot method yet, but i am confident that it works. I hear it's how some people do their kernel development and debugging stuff. ;D