> But there's not, so we let projects define their own models. Variable parameters much better to place in some config file (xml, ini and so on) than into source. It's like putting info from task header into processing app code. If info will not change, it's ok, but if it change... troubles begin. As I understood from last few messages, relevant parameters reside in sources, not in separate config file. If BOINC leaves their customizations to projects then there should be some stub config file, not stub source file perhaps.
And more about BOINC's problem re: partially resource usage. How current sheduler will manage CPU and GPU resourses for such app? I was unable to provide good enough app_info to allow max GPU utilization from one side and unattended run from another. App uses GPU only some % of time (namely, on FFA calsulations). That is, it's possible to run few tasks for better GPU utilizations. But number of running tasks should be determinad _not_ from % GPU usage, but from GPU memory usage. GPU memory resourse defines how many instances can be running at given time. Is it possible now? > > Eric J Korpela wrote: >> One point of generic resource allocation is that the resource >> definitions aren't in the source code, but are defined in XML. >> Requiring per app and per project server source customization is a >> problem, not a solution. >> >> On Sat, Dec 19, 2009 at 10:59 AM, David Anderson <da...@ssl.berkeley.edu> >> wrote: >>> Eric J Korpela wrote: >>>> This is part of the problem we face because we didn't treat resources >>>> in a generic manner in the scheduler. The ATI astropulse application >>>> only uses the GPU for parts of the application, and there's no means >>>> in the scheduler to deal with an application that uses 85% of a CPU >>>> and 10% of a GPU. Other than changing the scheduler code every time >>>> we release an new version of this app, that is. >>> That's what sched_customize.cpp is for. >>> It explicitly supports apps that use x% of a CPU and y% of a GPU. >>> There's no point in trying to define a "generic" model; >>> the next app to come along will break the model. >>> > > _______________________________________________ > boinc_dev mailing list > boinc_dev@ssl.berkeley.edu > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
