<div dir="ltr"><div><div><div><div>Hi,<br><br></div>I would like to contribute to this thread a link to the international desktop grids federation at <a href="http://desktopgridfederation.org/">http://desktopgridfederation.org/</a><br>

</div>This community is quite active in Europe and perhaps in other parts of the world. They deploy BOINC and derivatives and run conferences to discuss applications that can benefit from desktop grid type of computing.<br>

<br></div>Best regards,<br></div>   Dima<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 26, 2013 at 8:00 PM, Ivan M <span dir="ltr"><<a href="mailto:ispmarin@gmail.com" target="_blank">ispmarin@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi folks,<br><br></div>I have access to a bunch (around 20) machines in our lab, each one with a particular configuration, usually some combination of Core i5/i7 and 4GB/8GB/16GB RAM (the "heterogeneous" part), connected by a 24 ports Cisco switch with reasonable backplane. They're end user machines, but with the current lab occupation only a fraction of them are used constantly, but which ones change every day. They are all running Debian stable. I got an idea: why not use the downtime to run some parallel simulations, instead of using the university cluster?<br>



<br></div>They main problems now are:<br><br></div>1) System administration: for now I'm doing the clusterssh way to update/configure/install new software, but this can be very cumbersome, as one of the machines can be being used and so I can't change its configuration, so I have to keep track of which ones have changed. Maybe puppet can help here?<br>



<br></div>2) Managing resources: knowing which machine is up and available withou having to shout, and knowing the available configuration to allocate jobs that can fit in that particular machine, etc. There are extreme cases when the machine needs to be rebooted to run some Windows program.<br>



<br></div>3) Migrating jobs (the intermitent part): any machine can be requested by a user at any time, so if I have a parallel job running I would have to migrate the job to another machine, preferably without stopping the other jobs. We are running mostly ROMS over MPI and some in-house simulations that use a combination of OpenMP and MPI. <br>



<br></div>Does anyone have any experience or pointers on how to address these issues? It seems a waste not to use those idle machines...<br clear="all"><div><div><div><div><div><div><div><div><div><div><div><div><div><div dir="ltr">



<br>Ivan Marin<span style="display:block"><a href="http://scholar.google.com.br/citations?user=faM0PCYAAAAJ" target="_blank">http://scholar.google.com.br/citations?user=faM0PCYAAAAJ</a></span><br></div></div>
</div></div></div></div></div></div></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
<br></blockquote></div><br></div>