diskless clients? beowulf-newbie seeks advice

[Pedro Díaz Jiménez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 22 June 2001 21:42, Jared Hodge wrote:
> > I partially agree. Your thoughs on memory management?. Swap over Network
> > would decrease greatly the performance, so in my opinion you are limited
> > to non-memory-consuming computations
>
> 	Wow, someone asking for my thoughts, how gratifying.  Really this may
> sound a little trite, but if you're having to intensively swap for a
> single application, you're already up the creek without a paddle.
> Really as cheap as memory is, you can load up your nodes with a few Gigs
> each and there shouldn't be much of a problem.  In fact, we've got hard
> disks on our cluster, but I have swapping disabled because I want the
> programs to crash when they try to swap.  I know that sounds strange,
> but I would rather our programmers (who are physicists, not computer
> scientists) know that something is wrong when they try a new code that
> is overly liberal with memory usage, than wonder why the cluster (that I
> am responsible for maintaining) is running so slow.  That way, if they
> want to get around the total actual memory available, they have to
> explicitly write to files and free some memory.  This extra work really
> motivates them to use memory efficiently.  I'm willing to turn swapping
> on for specific runs if they could justify why they need it (I'm sure we
> could work it into the PBS script), but so far the issue hasn't come up
> (I think it's kind of cool how I've used their ignorance to their and my
> advantage).  Really, swapping is best at keeping desktop PC's running
> even when they are overextended.  I don't think swapping is appropriate
> (in most circumstances) in high performance computing.

Seems interesting, but a little drastic to me. I agree, RAM prices are very 
low. But, OTOH secondary storage is cheaper. There are other tools to 
limit your users memory usage, and you'll always have a few spare gigs for 
secondary storage. What about a distributed filesystem or database?. 


>
> > IMHO Cray's are another beasts. Each micro has access to the main memory
> > via a high-speed bus. Thats not my situation (100Mbps) and probably not
> > the situation of most beowulfs
>
> 	Very true, Cray's are "currently" very different from clusters.
> However as GigE-Myrinet level networks become more common, the
> distinction becomes a little more blurry.  100 Mbps is probably not
> enough to support any type of network swapping, much less for large
> numbers of nodes (although really the latency is more of an issue than
> the bandwidth if you use a clever network topology).  Also, I really
> think we've started to get even "The Mighty Cray's" attention with our
> little Beowulf project, and if their smart they are heading more towards
> cluster styled systems also.  Really, I can't even tell the difference
> anymore between a true "supercomputer" and a cluster.  They may have the

I can. Its like looking at supermodel's photos. They look perfect, 
but you know you will never we close enough to one of those to tell if they 
really perform well :-)
   
> price and performance increase of using non-COTS hardware, but the goal
> is the same - to get parallel jobs done.

Seriously, maybe the problem to resolve is not the same, thats why cray's and 
such beasts still exists. I'm talking about high bandwitch/very very very low 
latency comunication between 'nodes'. Some problems are simply not suitable 
for clusters even with myrinet. Thats my humble opinion


Cheers


Pedro


- -- 

  __________________________________________________
 /                                                  \
 | Pedro Diaz Jimenez  - Undergraduate Living Form  |
 |                                                  |
 | pdiaz88 at terra.es      pdiaz at acm.asoc.fi.upm.es   |
 \__________________________________________________/

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDqcGZsRBADFIahNPLk8suMlS39m8RqatLgX4dO7PU2F5p1oVvkyB7PaLQCv
FREWwfrjGpxAjRnxyZ4TdaFi1oCP495t5R2CdjPZu0EfjsEqosdLXkjDsKl2n4Wo
Afb6BaHMJS5PADEI0QfpZOkB8OruAZja/oGmn5rThyjgCxWHUuK1ArmeGwCg7+9a
owg9wP1RohePHJSDB9d2HYMD/i7z1X4ev+K90LumgJwSWlScJ7MEip5rw4wqGOkK
lF/C2nTYsoX5CVEn/pu7hROL/BWIYtBgkNDaEjsVsyb+4KjQXcZUW5l3ADipWYx2
r9s4sFfeZ9nfhDcG0aNYRcCNkYSZ/WxUkXS8UjVEAEhkFu1BA+6UZmeq3pKtJZTR
+HqKA/9zRmgTon36zt2qe9eiR6DyY0EpGEI0iY+KYX6GC/wxizeHBw0FW1eOEoxF
GjtxdBv/U9vi7Vgav6aY+pr4la5q6jVabe03Y8yGDFeL8jM+lqww1rzpABiGrF+W
qge65zCUjL3jJE5+5yi+KcRyllb1OA7uXQTtsRw+TGq9Dvaaz7QwUGVkcm8gRGlh
eiBKaW1lbmV6IChCLk8uRi5ILikgPHBkaWF6ODhAdGVycmEuZXM+iFYEExECABYF
AjqcGZsECwoEAwMVAwIDFgIBAheAAAoJEJ7ud33hGMZRj20An2Ce4S/vBTuZDxnL
WFBrJRnc3UdaAKDnIPNRbz7r4dh9AuBcpbCE1pQ/SLkBDQQ6nBmqEAQAr7O07Dws
5zAbQvm1hwGthXKCHtIIuWCPdX/XkNG6ZxV/cXgs4LI4oAg3GhttD2JIEk2SoVXE
FOf/wIddIDz70/9mIZavMvpR31LxBFSJk0Up3caOvThM90wMttRi7tg7cf04rrMM
Phy8T5bOIW/q5SMwZffbJXD7bA0/jDLdQ6MAAwYD/1emSwNTzOOmMCZadoEBpKIE
HA35P2/m/SsCI+pQ/OKXKPvvrQKTQqRCcDa5aq31oSiT9M5WQ96BlIGKHRPWGpvm
0822V7M9RF2mYZPIfgKfTSvZpYHzjz+RM7PvBBiBc9l95vy70Sh7SywIF86H80Ag
D0dUIDtGlrSANhXjx4EJiEYEGBECAAYFAjqcGaoACgkQnu53feEYxlHdVACgjVhU
Y8CKf6MYZgQOR9eIDNvTX0AAn3dwbW1HLxEF5OQKJIsngl0BUlYK
=d4S3
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7M9xcnu53feEYxlERAs7cAJ44dfhb41GIIFb79CncQ4X1jmAKIgCfT332
9uLonUJAURzrjGx1tVw8EM4=
=mWSd
-----END PGP SIGNATURE-----