(Note: In a thread discussing fault tolerance, the concept of multiple managers was brought up, so I figure I ought to mention my thoughts on the subject.)
One of the things I'd been thinking of is how to modify the Executor functionality and GUI so that it gives the "end user" more control over what's happening. While I don't think that fine grained control over threads is a good idea, I think that there should be a way to throttle the thread priority for all Alchemi threads running on their machine. The reason for this: when I was running my 'calculate pi to the 100k digit' test, there were times where certain operations on the machines ran extremely slow until the Executor was shut down (for instance, saving from a specific text editor). While I understand that the design is that only 'idle' resources are used, sometimes it seems that there are thread priority conflicts and some non-Alchemi things seem to be slowed down. Secondly, I also think that we should provide the ability for a single executor to connect to multiple managers simultaneously. I.e., a single machine can be part of one or more 'grids'. Through the GUI, the end user should be able to manage the priority of execution between these multiple managers. And an example for why this would be important. Say you have a company with an electrical engineering department and a mechanical engineering department. 1.) Each department has their own 'grid', that is, Manager, which they use to monitor and track jobs performed by their respective department. They need have complete and accurate information regarding these jobs and the GHz*Hrs consumed. 2.) Each department manages their own budget, which they can allocate toward various computational resources or otherwise 3.) In order to avoid wasted CPU cycles and extra machines sitting idle, some machines are set up to run jobs for both departments, but have a priority to the department which purchased the machine. Each department can keep track of jobs performed on the other's machines, and bill the other department appropriately, based upon the cost of purchasing the machine, the expected lifetime in GHz*hrs, and the actual GHz*hrs consumed, or some other measure. Even if no intra-department billing mechanism is implemented, being able to specifically track, manage, and administer tasks for their specific department while still using shared executing machines. And a second example, this time for with the 'consumer' user. Let's say some gaming company has come up with a grid-enabled game, and you and your friends get together to play. You decide to set up a grid of all your machines specifically for running this game, but you're also a member of some other grid like, say, an Alchemi-enabled [EMAIL PROTECTED] This way your machine could be a member of multiple grids, and perform tasks for each of these grids, but isn't dedicated to either of them. Sort of the power of a p2p system via opt-in and throttling, but while still retaining the centrally-managed and administered features of Alchemi. Thoughts? Jonathan Mitchem ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ alchemi-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-users
