I don't completely follow this. If your app_info.xml specifies that app versions use coprocessors that the client knows about (NVIDIA or ATI) then jobs using those app versions will always run, regardless of CPU usage.
It sounds like what you're requesting is a way for app_info.xml to refer to coprocessor types that the client doesn't know about, and have BOINC schedule jobs accordingly. The app_info.xml file would also have to specify how many instances of the resource there are. This would be a major new feature, and I don't think the cost/benefit ratio justifies it right now. -- David Raistmer wrote: > Problem what I see in short: BOINC is negatively affects on system > performance by suppressing app that make use of non-CPU accelerator. > > I use "accelerator" word instead of GPU cause what I've seen earlier with > CUDA and what I see now with ATI GPU is just particular cases of "BOINC & > accelerator" problem. > > If BOINC informed that particular app not need 100% of CPU core it could > infere that this app will use some other resource, lets call it accelerator, > part of time (it can be just heavely accessed HDD in fact, but nevertheless, > let it be accelerator). > > That is, by all means such app should have required small CPU share - or > performance loss will occur. But currently BOINC blocks such apps from > executing at all just because some another CPU-based app go in high priority > mode. My ATI GPU estimated as 1248GFLOPS (by BOINC itself), much higher than > all CPU 4 cores in total - and all this power will be lost just because BOINC > running 4 SETI apps in high priority mode.... > > Yes, I know that "BOINC will have ATI GPU support" from 6.10 versions. But > this doesn't solve described problem at all. For this "support" to work > _project_ should do support such hardware from server side too by separate > work issue. But, for example, SETI have no ATI GPU based stock app at all > now. For what reason SETI project should produce separate work for this > hardware then? > > And what will be if some other super-fast GPU or something alike appears? > Next half-year of "no-use" and next separate work issuer and separate set of > options and dedicated "support" ? > > My point is - current hardware supporting approach in BOINC is inadequate. > Why BOINC need to know that host has specific accelerator installed? : > (please, add if I missed something) 1) To be able to download appropriate > software 2) to be able to download appropriate work (BUT not always such work > should be different from CPU work, actually SETI issues absolutely SAME work > for GPU and CPU, almost all other GPU-supporting projects do the same AFAIK) > 3) To be able to do correct scheduling. > > If we use anonymous platform, 1) and 2) already defined by app_info creator. > BOINC will just use supplied info. > > So, if anonymous platform app can use CPU work supplied by project, why BOINC > requires to have different work for it (currently CUDA work treated by BOINC > as completely separate entity AFAIK, separate debts and so on). All BOINC > needs in case of anonymous platform is some info to be able to deal with 3) - > correct scheduling. And it's not possible in current approach w/o help from > server side (separate work issue!). That is "anonymous platform" no more > anonymous, project should know it very much and do direct support (!). > > But actually, all BOINC needs is _description_ of anonymous resource I called > accelerator. This description can and should be supplied by application > writer. Having such description (i.e share of CPU used by program, share of > this accelerator used by program, is it possible to do checkpoint for this > program, how costly app swap for this resourse and so on) BOINC will be able > to do perfect scheduling w/o even know how this resource called outside of > app_info file. All we need is common names for such resources and ability to > introduce new ones in anonymous platform. > > For example if one project noted ati_gpu in app_info and another one noted > ati_gpu in its app_info - BOINC will know these two apps from these 2 > projects will compete for resource named ati_gpu. It even could not know that > ati_gpu resource is video card and not an some other accelerator. It just > should try to busy all known accelerators, that's all. > > Current approach doesn't allow to introduce such resource for anonymous > platform. > > I hope I described what problem I see. > > ----- Original Message ----- From: David Anderson To: Raistmer Sent: > Thursday, September 10, 2009 2:04 AM Subject: Re: [boinc_alpha] BOINC 6.10.4 > abuses high priority mode > > > Your message log did reveal some problems, which I fixed. But I no longer > understand what problem you're seeing. Does your app_info.xml say that your > s...@home Beta app uses a GPU? If not, the scheduler won't treat it > specially, i.e. it won't run it if the CPUs are in use by other jobs. -- > David > > Raistmer wrote: >> Currently only 2 SETI task running in high priority mode though The main >> issue how I see it not in high priority mode itself but in fact it disable >> ability to run slightly more total CPU than 1 per core. For example, now on >> my quad 2 SETI tasks running, 2 SETI tasks running in high priority and 3 >> (avg_cpu=0,245) SETI beta tasks running instead of 4 when no SETI tasks >> running in high priority. Logs listed: >> >> >> 10/09/2009 01:18:11 Re-read config file 10/09/2009 01:18:11 log flags: >> task, sched_ops, cpu_sched_debug, rr_simulation 10/09/2009 01:18:11 >> [cpu_sched_debug] Request CPU reschedule: Core client configuration >> 10/09/2009 01:18:11 [cpu_sched_debug] schedule_cpus(): start 10/09/2009 >> 01:18:11 [rr_sim] rr_sim start: work_buf_total 1728000.00 on_frac 1.000 >> active_frac 1.000 10/09/2009 01:18:11 milky...@home <mailto:milky...@home> >> [rr_sim] 0.00: > > _______________________________________________ boinc_alpha mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha To unsubscribe, > visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
