CPU <-> GPU rebranding

[Raistmer]

Search these boards. Some time ago I posted curve for GPU/CPU relative performance from AR.
Short answer - ReShedule does the best task distribution when it moves VLARs and VHARs to CPU.
GPU best suited for midrange ARs.

[Fredericx51]

It works beautifull, only my X64 host, has sometimes, troubles, lost connection to local host, connecting. . . . .
REVerting to 'older'Drivers, 190.38 & 190.61 put an end to this and 'oher' UNexplained error's, which appeared to be heat problems and 'flat' the 'tower' ,   layed it on it's side
Even on VISTA Home Premium 32BIT, it works
And when I see 1 host with only CUDA and VHAR, then those are partly REbranded again for CPU.

[Marius]

Thanks Joe

Any reason for not putting it in the download section. I read a few pages in and noticed the original post was getting updated with every new version so gave up there thinking the OP had the latest version.

The primary reason is Marius is missing in action and not here to support his program. Need more be said?

  Actually i have never left and i'm still reading threads but not as much as i would like as i'm very busy..

[SETI-GPU-process]

  Actually i have never left and i'm still reading threads but not as much as i would like as i'm very busy..

Rumors of Marius' demise have been greatly exaggerated.

[Pepi]

It works beautifull, only my X64 host, has sometimes, troubles, lost connection to local host, connecting. . . . .
REVerting to 'older'Drivers, 190.38 & 190.61 put an end to this and 'oher' UNexplained error's, which appeared to be heat problems and 'flat' the 'tower' ,   layed it on it's side
Even on VISTA Home Premium 32BIT, it works
And when I see 1 host with only CUDA and VHAR, then those are partly REbranded again for CPU.

Heat problem you say? I have two comp: one is 24/7 with GTX 260 190.38 drivers and one is GT 240 with latest drivers from Nvidia. Ok I can understood that in noon I have heat problem ( my comp is on my balcony open case covered from sun, but I have same errors in midnight, so I doubt that I have "heat problem" then. So I suspect on older drivers as main reason of those errors

GPU temp never rise above 72°C so as I know that is low temperature for GTX 260 ( or maybe my sensor is broken) and card is overheating?
I the other side GT 240 with latest drivers have same error but only one or two in seven days, compared to few that I have with GTX 260 in one day

PROBLEM SOLVED: in my case it was weak power supply After replacement I have no more errors.

[Geek@Play]

While I agree with Mark and Joe on the commitment to crunch all work assigned to the client computers, in reality it is unrealistic to expect this commitment to be achieved.

Using the Rescheduler tool to move the VLAR work to the CPU's very quickly overwhelms the CPU's.  There are days when 2 or 3 times the work being moved than the CPU's are capable of in one day.  The CPU's fall behind with the ever increasing larger cache for the CPU's work and eventually work starts being crunched too late.

I have then stopped using the Rescheduler tool to move the VLAR work to the CPU's.  The CPU's can crunch the work assigned to them, including the VLAR work.  I have also swithed the the "killer" app for the GPU's so the VLAR assigned to the GPU's will error out.

I do not care for this procedure as I feel that I am cherry picking the work.  But in fact this is the only way that the client computers can run without constant attention to them.

If there is a better solution I am open for suggestions.

[sunu]

Yes if you have a high output machine, that is with many GPU cores, the amount of VLARS gets out of hand very quickly and your CPU can't hope to finish them not even after a month. If you use that machine and you care about it's responsiveness, you don't have other option than to abort them.

Well, if you're really determined to crunch them all, you could wait that month and see at the end that you really can't do them all and you have to ditch them after so much time sitting on them. And that would be worse.

[SciManStev]

I am still in a learning curve here, so this may have been discussed before. Sincs GPU's are not well suited for VLAR's, is there a way for S@H to only brand them for CPU use? That might help to balance the total work load. I recently depleted my cache to prepare for getting my GTX 480's crunching, and it took a coule of days to run out of GPU work, and close to two weeks to run out of CPU work. I attributed this to the VLAR's being rebranded for the CPU. If they came for CPU's in the first place, then it seems that the load would have been more balanced.

[Vyper]

is there a way for S@H to only brand them for CPU use? That might help to balance the total work load.

This has been questioned before and for the moment the s@h servers doesn't do an AR analyse before sending it to a GPU host on their side.
The only two solutions is either by using Rescheduler for the moment or older series 2xx series and down can use a prepared VLAR kill .exe that checks the wu and if it's a VLAR then it's killed instantly.

Regards Vyper

[Gecko_R7]

.... Sincs GPU's are not well suited for VLAR's, is there a way for S@H to only brand them for CPU use? That might help to balance the total work load. I recently depleted my cache to prepare for getting my GTX 480's crunching, and it took a coule of days to run out of GPU work, and close to two weeks to run out of CPU work. I attributed this to the VLAR's being rebranded for the CPU. If they came for CPU's in the first place, then it seems that the load would have been more balanced.

I'll wade-in to answer your question Steve, but hope Devs. will correct me if I'm mistaken.
The project doesn't discriminate WUs to specific hardware and a WU can be assigned to any host w/ compatible OS and CPU and/or GPU.
The WU could be assigned to an Atom running Linux,  a PowerPC 800 Mhz chip running OSX, or a 9400GT GPU.
From the project's perspective, there are such a wide range of performance differences with all the eligible hosts out there, that WU could just as easily be assigned to a Pentium III, as to a GTX285.  Whether fast, or slow, if it falls into a supported HW/SW platform that can complete and validate by deadline, then the project considers it acceptable.

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.

For a 2nd project, the efficiency/production gain would have to justify the additional expense and resources required at the project level.
Both of which are barely enough to support the current effort.

[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]

... 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.
...

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]

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

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.