On 1/13/12 7:18 AM, "Douglas Eadline" <[email protected]> wrote: >> >> >> And Doug, your small systems have a lot of the same issues, perhaps >> because that small Limulus might be operated in environments other than >> what the underlying hardware was designed for. I know people who have >> been rudely surprised when they found that the design environment for a >> laptop is a pretty narrow temperature range (e.g. office desktop) and >>when >> they put them in a car, subject to 0C or 40C temperatures, if not wider, >> that things don't work quite as well as expected. > >I will be curious to see where these things show up since >all you really need is a power plug. (a little nervous actually).
Yes.. That *will* be interesting... And wait til someone has a cluster of Limuluses (Not sure of the proper alliterative collective noun, nor the plural form.. A litany of limuli? A school? A murder?) > >I agree. Four nodes is really small. BTW, the most fun in designing >this system is a set of tighter constraints than are found on the typical >cluster. Noise, power, space, cabling, low cost packaging, etc. I have >been asked about a rack mount version, we'll see. > >One thing I find interesting is the core/node efficiency. >(what I call "effective cores") In general *on some codes*, I found that >less cores (1P micro-atx 4-cores) is more efficient than many >cores (2P server 12-core). Seems obvious, but I like to test things. Yes, because we're using, in general, commodity components/assemblies, we're subject to the results of optimizations and market/business forces in other user spaces. Someone designing a media PC for home use might not care about electrical efficiency (there's no big yellow energy tags on computers, yet), but would care about noise. Someone designing a rack mounted server cares not a whit about noise, but really cares about a 10% change in power consumption. And, drop on top of that the non-synchronized differences in development/manufacturing/fabrication generations for the underlying parts. Consumer stuff comes out for the winter selling season. Commercial stuff probably is on a different cycle. It's not like everyone uses the same "model year changeover". > >> >> >> (oddly, simulated fault injection is one of the trickier parts) >> > >I would assume, because in a sense, the black swan* is >by definition hard to predict. Not so much that, as the actual mechanics of fault injection. Think about testing error detection and recovery for Flash memory. The underlying specification error rate is something like 1E-9 or 1E-10/read, and that's a worst case kind of spec, so errors aren't too common (I.e. You can't just run and wait for them to occur). SO how do you cause errors to occur (without perturbing the system.)... In the flash case, because we developed our own flash controller logic in an FPGA, we can add "error injection logic" to the design, but that's not always the case. How would you simulate upsets in a CPU core? (short of blasting it with radiation.. Which is difficult and expensive.. I wish it was as easy as getting a little Co60 gamma source and putting it on top of the chip.. We hike to somewhere that has an accelerator (UC Davis, Brookhaven, etc) and shoot protons and heavy ions at it. > >(* the book by Nick Taleb, not the movie) Black swans in this case would be things like the Pentium divide bug. Yes.. That *would* be a challenge, but hey, we've got folks in our JPL Laboratory for Reliable Software (LARS) who sit around thinking of how to do that, among other things. (http://lars-lab.jpl.nasa.gov/) Hmm.. I'll have to go talk to those guys about clusters of pi or arduinos... They're big into formal verifications, too, and model based verification. So you could have a modeled system in SysML or UML and compare its behavior with that on your prototype. > > >-- >Doug > >-- >This message has been scanned for viruses and >dangerous content by MailScanner, and is >believed to be clean. > _______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
