Complete.Org: Mailing Lists: Archives: discussion: December 1999:
[aclug-L] Re: My Boewulf... sorta
Home

[aclug-L] Re: My Boewulf... sorta

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: aclug-L@xxxxxxxxxxxx
Subject: [aclug-L] Re: My Boewulf... sorta
From: Jonathan Hall <jonhall@xxxxxxxxxxxx>
Date: Fri, 17 Dec 1999 02:28:04 -0600
Reply-to: aclug-L@xxxxxxxxxxxx

On Thu, Dec 16, 1999 at 11:23:41AM -0600, John Goerzen wrote:
> Jonathan Hall <jonhall@xxxxxxxxxxxx> writes:
> 
> > Well, I have, in a manner of speaking, a Boewulf cluster in my bedroom now. 
> > I don't know if it technically qualifies as a Boewulf, but I think it does.
> 
> Not Beowulf, since you're not using the Beowulf software, but it is a
> (rudimentary) distributed processing system.

Yes, that was my concern... although I've not been able to find any
reference to actual "Boewulf software."  Every instance of a production
Boewulf I've come across runs different software--usually highly customized
to the application at hand.

Although my setup is not distributing a "single" task across multiple
systems...

Is there a formal definition to a "Boewulf"?  Or are there other formal
definitions for classes of clusters or distributed computing applications?

What does the RC5 (and other distributed.net projects) qualify as?


> > I can probably outperform John's 600Mhz Alpha with this setup, when encoding
> > 4-5 MP3s at once (when encoding a single MP3, John still obviously wins, b/c
> > he can contribute the entire 600Mhz to the encoding, whereas I only get to
> > utilize my full 1136Mhz when encoding 5 MP3s at once :-)  John still may win
> > even when doing 4-5 MP3s at once, b/c he doesn't have to transfer his MP3s
> > over 10mbit ethernet to each of his nodes.  :-)
> 
> The Alpha generally can encode at about 4x realtime.  However, this is 
> an estimate, because I have never actually used it to encode when
> there was not significant other stuff going on (gcc, gimp, etc).  It
> may be plus or minus 1x that figure.  Furthermore, this is always with 
> the 'absolute best quality output' selected, which generally causes
> encoding to be slower.

I found a much better encoder which not only produces far superior sound
quality, but encodes at 4-5x realtime on my K6-III.  I doubt it will work on
your Alpha, though, as it is highly x86-optimized, thus uses much assembly
language.  :-)


> > Well, I guess that's all I have to say about that.  It's kind of a fun
> > little project. :-)
> 
> Yes, very interesting, people here may be interested in your scripts.
> 
> Incidentally, I think you mentioned a dual machine.  You may get
> improved performance if you can run two encoders on that machine
> simultaneously.

I was doing that w/ 8hz-mp3.  gogo (the new encoder I've found) has
multitreading support, so can encode a single MP3 on both CPUs
simultaneously.


> > P.S. I hope you don't mind me using your computer as a comparison, John. 
> 
> No problem at all :-)
> 
> > BTW, what kind of encode-time/play-time ratio do you get when encoding MP3s
> > on your Alpha @ 128kbps?  (I'm using 8hz-mp3... which encoder do you use?)
> > :-)
> 
> I believe I have lately been using LAME, but I did use BladeEnc
> before that.  I really don't do a significant amount of encoding, so
> I'd have you double check.


--
Floppy disk tip #5: Data access time may be greatly improved by cutting more
holes in the diskette jacket.  This will provide more simultaneous access
points to the disk.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Jonathan Hall  *  jonhall@xxxxxxxxxxxx  *  PGP public key available
 Systems Admin, Future Internet Services; Goessel, KS * (316) 367-2487
         http://www.futureks.net  *  PGP Key ID: FE 00 FD 51
                  -=  Running Debian GNU/Linux  =-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[Prev in Thread] Current Thread [Next in Thread]