From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 19 19:15:34 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E1E1065670 for ; Wed, 19 Mar 2008 19:15:34 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 71D288FC23 for ; Wed, 19 Mar 2008 19:15:34 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 18864 invoked from network); 19 Mar 2008 19:15:33 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 19 Mar 2008 19:15:33 -0000 Message-ID: <47E16514.7090203@chuckr.org> Date: Wed, 19 Mar 2008 15:10:12 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Jeremy Chadwick References: <47DF1045.6050202@chuckr.org> <20080318082816.GA74218@eos.sc1.parodius.com> <47E146F9.5060105@chuckr.org> <20080319172213.GA28075@eos.sc1.parodius.com> <47E1558A.2030107@chuckr.org> <20080319184244.GA29838@eos.sc1.parodius.com> In-Reply-To: <20080319184244.GA29838@eos.sc1.parodius.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Hackers Subject: Re: remote operation or admin X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 19:15:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Chadwick wrote: > On Wed, Mar 19, 2008 at 02:03:54PM -0400, Chuck Robey wrote: >> Well, I am, and I'm not, if you could answer me one quiestion, then I would >> probably know for sure. What is the difference between our SMP and the >> general idea of clustering, as typified by Beowulf? I was under the >> impression I was talking about seeing the possibility of moving the two >> closer together, but maybe I'm confused in the meanings? > > SMP as an implementation is mainly intended for single systems with > multiple processors (e.g. multiple physical CPUs, or multiple cores; > same thing). It distributes kernel operations (kernel threads) across > those processors, rather than only utilising a single processor. > > Clustering allows for the distribution of a task (a compile using gcc, > running of certain disk I/O tasks, running multiple userland (or I > suppose kernel, if the kernel had clustering support) threads) across > multiple physical computers on a local network. > > The best example I have for real-world clustering is rendering (mostly > 3D, but you can "render" anything; I'm referring to 3D in this case). > > A person doing modelling creates a model scene using 3D objects, applies > textures to it, lighting, raytracing aspects, vertex/bones animation, > and anything else -- all using their single workstation. Then the > person wants to see what it all looks like -- either as a still frame > (JPEG/PNG/TIFF), or as a rendered animation (AVI/MPG/MJPEG). > > Without any form of clustering, the workstation has to do all of the > processing/rendering work by its lonesome self. This can take a very, > very long time -- modellers aren't going to wait 2 hours for their work > to render, only to find they messed up some bones vertexes half way into > the animation. > > With clustering, the workstation has the capability to send the > rendering request out onto the network to a series of what're called > "slaves" (other computers set up to handle such requests). The > workstation says "I want this rendered. I want all of you to do it". > Let's say there's 200 machines in the cluster as slaves, and let's say > all 200 of those machines are dual-core (so 400 CPUs total). You then > have 400 CPUs rendering your animation, versus just 2 on the > workstation. > > The same concept can apply to compiling (gcc saying "I want this C file > compiled" or whatever), or any other "distributed computing" > computational desired. It all depends on if the software you want to > support clustering can do it. > > Different clustering softwares run at different levels; some might act > as "virtual environments", thus underlying software may not need to know > about clustering (e.g. it "just works"); others might require each > program to be fully cluster-aware. > > Make sense? :-) Not completely yet (I tend to be stubborn, if I carry this too far, tell me in private mail and I will politely drop it). Your use cases show me the differences in size, and *because* of the size, the differences in how you'd use them, and that part I did already know. I'm perfectly well aware of the current differences in size, but what I'm after is what are the real differences, ignoring size, in what they actually accomplish, and how they go about doing it. I'm thinking of the possibility of perhaps finding it it might be possible to find some way to extend the work domain of an smp system to stretch across machine lines, to jump across motherboards. Maybe not to be global (huge latencies scare me away), but what about just going 3 feet, on a very high speed bus, like maybe a private pci bus? Not what is, what could be? And, I have experienced just as many looniees as you have, who ask for some gigantic task, then sit back and want to take the credit and act like a cheerleader, figuring they really got the thing going. Well, I DON'T really want the help, I have in mind a project for me and a friend, with small smallish machine resources, maybe a bunch of small ARM boards. I wouldn't turn down help, but I'm not really proselytizing. Something small, but with a bunch of bandwidth. So, in that case, what really are the differences between smp and clustering, besides the raw current size of the implementation? Are there huge basic differences between the clustering concept and by smp's actual tasks? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4WUUz62J6PPcoOkRAoJNAJ4o4jpDeVlLG2X6Sk1ccggORyO2GwCgku/s U3w/oylwEgt8CufFZwccfw4= =zbNA -----END PGP SIGNATURE-----