--- On Sat, 2/6/10, Predrag Punosevac <punoseva...@gmail.com> wrote: > From: Predrag Punosevac <punoseva...@gmail.com> > Subject: Re: Building a High-performance Computing Cluster Using OpenBSD > To: misc@openbsd.org, list-...@designtools.org > Received: Saturday, February 6, 2010, 10:56 AM > "J.C. Roberts" <list-...@designtools.org> > wrote: > > > On Fri, 05 Feb 2010 23:39:19 -0500 Predrag Punosevac > > <punoseva...@gmail.com> > wrote: > > > > > Dear All, > > > > > > Could anybody kindly point me to any literature > regarding > > > building a high-performance computing cluster > using OpenBSD. I am not > > > interested in FreeBSD and NetBSD related papers > on this topics. I can > > > find them easily. I am specifically interested in > OpenBSD. > > > Applications I am planning to run are related to > Bifurcation Theory. > > > > > > Thank You, > > > Predrag Punosevac > > > > Pendrag, > > > > At one point in time, the phrase "High Performance > Computing" (HPC) > > actually meant something fairly specific, but over the > years it has > > degraded to an exceedingly vague buzzword. > > > > In the classic sense of HPC where you're doing > significant amounts of > > computation on problems requiring tightly coupled > nodes (i.e. hard > > parallelization), > > That is exactly what I have in mind. I have computations > which can be > parallelized and which currently require in upward of a > week to preform. > Usually, after a week we see that we didn't get quite right > the initial > conditions and we are repeated the thing. After half dozen > iteration > we usually get things right. That takes about 2 months. We > have a pile > of blades (i386/amd64) laying around and my idea > (even that I have never done that) before is that we > tightly couple > and try to reduce the computation time to less then a day > per > computation.
> > asking for OpenBSD specific papers on this topic is > > the equivalent of asking for papers on using a hammer > to trun a screw. > > > > In the case of using classic HPC on hard > parallelization problems, > > OpenBSD is the wrong tool for the job. The reason is > OpenBSD does not > > support vast amounts of RAM, and it doesn't have > support for fast > > memory interconnects (Myrinet, SCI, ...). > > > > I had a hunch that OpenBSD is a wrong tool but I wanted to > make sure > that I am not missing anything. That is why I posted the > question. > C.J. which OS would you pick. A main FreeBSD paper on > cluster computing > is from 2003 when SMP support was immature. Now they have > ULE, good SMP > I would have to check for other things. NetBSD mailing list > tech-cluster > is dead. NetBSD amd64 does support lots of RAM. They seem > to have a > great SMP support now. I see that NetBSD was used in the > past for those > things. I would still go with GNU/Linux unless you're dead set on a BSD in which case FreeBSD would be your best choice from a performance standpoint. > If it has to be Linux would you go with a RedHat? Or a RedHat derivative such as CentOS or Scientific Linux. > Please tell me little bit more. > > > > > If the problems you're trying to solve do not have > intensive memory > > requirements and qualify as easy parallelization > (a.k.a. > > "Embarrassingly Parallel"), then you do not need a > tightly coupled > > cluster and OpenBSD could be a good choice. > > > > In essence, it comes down to the specific problem(s) > *YOU* are trying > > to solve, so you *REALLY* need to elaborate on your > problem domain(s) > > and how you are trying to solve them. > > Well I said it is computation of Bifurcations around > homoclinic orbits > as well as computing of fast responding curves. I just got > in into the > team. At this point I am not even sure if the simulations > by co-workers > want to do are events of positive measure. I am thinking > about it. > I am more of a guy who is proving theorems rather than > trying to > compute something but as you can see I do not mind getting > my hands dirty. Embarrassingly Parallel can be interpreted two different ways as the term parallel can be interpreted to mean, I have a job that takes 1-n parameters and I want to run as many tests in parallel as possible or, I have a job that can easily have its problem domain split across 1-n nodes. Which does your target? Does your problem set fit within the confines of a single nodes memory? If not inter-node interconnect is going to become an issue especially if there is a lot of inter-node communication taking place. We have a Torque+Maui+CentOS 5 cluster with 68 nodes and 628 cores which is GigE connected and since the majority of our jobs are serial, thousands of jobs with different parameters simultaneously or little inter-node communication it works just fine. For weather simulations it certainly would be much better to have Infiniband. I'm not entirely familiar with your problem set but based on some, albeit rudimentary reading, inter-node *could* be an issue for you. __________________________________________________________________ The new Internet Explorer. 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
