Bonic Middleware Server

Message boards : Questions and problems : Bonic Middleware Server
Message board moderation

To post messages, you must log in.

AuthorMessage
jakeman95

Send message
Joined: 12 Dec 12
Posts: 3
United States
Message 47055 - Posted: 5 Jan 2013, 6:12:56 UTC

So, I wasn't all sure where to put this question or where to even look as I'm not sure what it would be called; however, as its more of a question of possibility and "how to" I guess the "questions" forum would be best.

I have access to random computers for several days at a time, as I do computer repair as a side job/hobby. I hate just leaving them sit there when I'm not working on them, but installing Boinc outright would be a waste as the computer would only be running it for 1 maybe 2 days (not to mention, I don't want to just install it on whatever OS is on the computer as the customer may not want it).

So, I thought about setting up a PXI boot type setup I've read about and I was about to do it; however, I then realized there are times I go weeks without having an extra computer where there are other times I have 5+ so that would be many tasks that would end up partially done and then never finished (eventually would be timed out by the Boinc server). So I instead thought that there might be a way to setup something like the PXI solution where it would provide packages to the individual computers which would on a normal schedule write its task save state to the server OS. Then, when tasks are left unfinished, the server OS itself would finish the computation of incomplete "abandoned" tasks. This would give the appearance of 1 system but with differing numbers of processors as differing numbers of systems that PXI boot from the server are ran.

This seems like it would be useful for something like computer repair shops that would want to run Boinc on systems they keep over night to help out but not actually install it on customer systems. It would also be handy at my place of work where we have physical systems go in and out of use at random and can't have the actual Boinc client running on it when in production.

I realize there might not be anything that fits this, and that the PXI boot option may be my closest option, but I thought I would ask the question before putting together the PXI boot system and eventually find out there was something better.

Also, one other side question. Are there any known issues / limitations with running Boinc in a VM? I know there will be the normal VM performance hit, but I just want to make sure there aren't any known issues. Another way to do the above, if there isn't any direct way, would be to have the host server at scheduled intervals kick up a different pixi machine as a VM and compute it's tasks for a day at a time, then shut that one down, boot the next, and so on. At least then there aren't dropped tasks that are only partially completed (ie. wasted compute time on them).
ID: 47055 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15484
Netherlands
Message 47056 - Posted: 5 Jan 2013, 9:37:57 UTC - in response to Message 47055.  

You could of course run BOINC on those machines with a minimum cache, or even with a cc_config.xml file that has in its options:
<cc_config>
<log_flags>
</log_flags>
<options>
<fetch_minimal_work>1</fetch_minimal_work>
</options>
</cc_config>


This fetches one task per device (CPU and GPU). It requires BOINC 6.12 or better.

BOINC can be run from VM, for instance Virtual Box. It'll run normally on that, however it cannot run on GPUs as the virtual videocard is usually a low-end emulated card only, not capable of CUDA, CAL or OpenCL.
ID: 47056 · Report as offensive
kdsjsdj

Send message
Joined: 5 Jan 13
Posts: 81
Message 47058 - Posted: 5 Jan 2013, 12:28:08 UTC - in response to Message 47055.  

So, I wasn't all sure where to put this question or where to even look as I'm not sure what it would be called; however, as its more of a question of possibility and "how to" I guess the "questions" forum would be best.

I have access to random computers for several days at a time, as I do computer repair as a side job/hobby. I hate just leaving them sit there when I'm not working on them, but installing Boinc outright would be a waste as the computer would only be running it for 1 maybe 2 days (not to mention, I don't want to just install it on whatever OS is on the computer as the customer may not want it).


No, you definitely do not want to install BOINC on any computer you have not been asked to install it on. That would not be professional.

So, I thought about setting up a PXI boot type setup I've read about and I was about to do it; however, I then realized there are times I go weeks without having an extra computer where there are other times I have 5+ so that would be many tasks that would end up partially done and then never finished (eventually would be timed out by the Boinc server).


I hear you. It boots off PXI, everything is temporary, nothing left behind when the machine powersdown and returns to customer.

So I instead thought that there might be a way to setup something like the PXI solution where it would provide packages to the individual computers which would on a normal schedule write its task save state to the server OS. Then, when tasks are left unfinished, the server OS itself would finish the computation of incomplete "abandoned" tasks. This would give the appearance of 1 system but with differing numbers of processors as differing numbers of systems that PXI boot from the server are ran.


I remember talk of a BOINC middle server some years back but I don't know if it ever came to be. It wasn't quite what you're looking for though as it assumed the machines would stick around and finish tasks rather than abandoning them. The idea that the server would finish abandoned tasks is a unique idea and very clever. If I am not mistaken results must be returned by the host they were issued to. If not they are rejected by the project server. So all tasks would have to be issued to the middle server then farmed out to the gypsies (the machines that come and go like wandering gypsies) and ultimately returned to the middle server which then forwards the result to the project server.

The current BOINC client does not have that capability. You would have to create and code a client of your own if you wanted to implement that scheme. Really it would not be terribly difficult. All it would need to do is accept some input files or parameters and spawn a project's science application with those inputs. Many (but not all) project science apps run fine without being spawned by BOINC client. You can run them yourself in a terminal. In client_state.xml it gives the command line required for each science app and project admins will usually tell you how to run the command in standalone mode. The client and the science applications would be installed in the OS when it boots from PXI, you could use Jabber or some other protocol over TCP to instruct the clients on the gypsies. If they all shared an NFS mount named /netdisk they would simply need to be instructed something like "run app XYZ with /netdisk/tasks/input_s7359.0 as input, use /netdisk/tasks/slot_1/ for working directory". The checkpoints would thus be in a place the server could access if it needed to finish the task.

It would be simple to run one project that way, not many options or different cases to handle. Some clever hard-coded scripts combined with just the right stuff booting on PXI might handle it.

For the middle server you might be able to trick BOINC client into acting as the middle server. It gets a task, an external script suspends the task and passes it to a gypsy. The external script stops and starts the client at appropriate times and doctors client_state.xml. BOINC client exits, a task completes on a gypsy, BOINC client starts and sees a completed task recorded in client_state.xml so it uploads the task oblivious to the fact the task ran on a gypsy. Reminiscent of the story in The Elves and the Shoemaker tale except the shoemaker never gets wise to what goes on while he sleeps.

This seems like it would be useful for something like computer repair shops that would want to run Boinc on systems they keep over night to help out but not actually install it on customer systems. It would also be handy at my place of work where we have physical systems go in and out of use at random and can't have the actual Boinc client running on it when in production.


A lot of BOINC farmers here would be interested in something like what you're talking about as they could run a farm of diskless, headless hosts booting off PXI. You should get together with Dotsch. He's already built some of what you need but not the middle server.

I realize there might not be anything that fits this, and that the PXI boot option may be my closest option, but I thought I would ask the question before putting together the PXI boot system and eventually find out there was something better.


Don't take my word for it but I don't think you'll find anything like what you need.

Also, one other side question. Are there any known issues / limitations with running Boinc in a VM? I know there will be the normal VM performance hit, but I just want to make sure there aren't any known issues. Another way to do the above, if there isn't any direct way, would be to have the host server at scheduled intervals kick up a different pixi machine as a VM and compute it's tasks for a day at a time, then shut that one down, boot the next, and so on. At least then there aren't dropped tasks that are only partially completed (ie. wasted compute time on them).[/quote]
ID: 47058 · Report as offensive

Message boards : Questions and problems : Bonic Middleware Server

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.