Forum > GPU crunching
CPU <-> GPU rebranding
SciManStev:
Thank you both. I understand now. I have been reading the threads, and realize that S@H has very few resources, and certainly doesn't need more responsibilities. It is amazing they have come as far as they have with such limited resources.
Steve
perryjay:
Thanks Gecko, I knew basically what you said but didn't know exactly how to say it so I stayed out of this one. And Steve, running projects on a shoestring is just what BOINC was designed for. SETI is pretty much the test bed for it though. I don't think they expected the shoestring to be quite as threadbare as SETI is. :-) That it has continued as long as it has with as little as it has is nothing short of a miracle!
perryjay:
More on subject though, I have been running the rescheduler since right after it was changed from a PERL script. (I was shaking in my boots thinking about having to figure out PERL! :-) ) I just keep my cache low enough so that it will get me through most outages but not so high that I get stuck with too many VLARs by rebranding that I can't get them done before they time out. I've only had a problem this way once but it was me changing something that required running my cache down right after we went through a VLAR storm. Not much you can do when all they send you are VLARs. I had to abort a few of them so that I could get it done before I chickened out! :-) I also keep the VLARKiller on my machine so that I don't get caught by a VLAR sneaking in after an outage but before the rescheduler kicks in. I've had this happen once or twice.
Josef W. Segur:
--- Quote from: Gecko on 29 May 2010, 09:58:16 am ---... hope Devs. will correct me if I'm mistaken.
...
Discriminating VLARs specifically for CPU would essentially require a S@H GPU subproject w/ a separate application, so you could run both S@H CPU and S@H GPU applications at the same time. However, this would significantly complicate the back end project requirements and maintenance by Berkeley.
...
--- End quote ---
It's not necessarily that complex. David Anderson added a feature to BOINC a few months ago intended for this. It requires the splitter to add something to the WU name which the Scheduler then recognizes and doesn't send such WUs to a CUDA host. It would be a fairly trivial splitter change, the code already has to deal with AR in order to set the rsc_fpops_est and related values appropriately. However, if the project were only splitting VLAR data then CUDA hosts might simply not get any work, the Scheduler change didn't include a method to send the work for CPU processing after it was judged unsuitable for GPU.
There was discussion on the boinc_dev mailing list concerning whether project cherry picking was any less reprehensible than user cherry picking. I pointed out that the only thing reprehensible about user cherry picking is the extra load on the servers from aborted tasks. I certainly think using participants' resources efficiently is a good idea, but I also suspect the typical user who reads the forums might find it difficult to see that difference between project and user actions which do similar things. BOINC is sufficiently advanced technology to be "magic" to many participants.
Joe
Gecko_R7:
--- Quote from: Josef W. Segur on 29 May 2010, 03:01:58 pm ---
It's not necessarily that complex. David Anderson added a feature to BOINC a few months ago intended for this. It requires the splitter to add something to the WU name which the Scheduler then recognizes and doesn't send such WUs to a CUDA host. Joe
--- End quote ---
Thanks for the insight Joe. Personally, I'm glad to see this feature included in BOINC and it let's the project decide whether it wants to support this.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version