Hi! >But I think you've chosen a poor example with the CPU-GPU speed relationship
Agreed, and I hope I didn't open a can of worms here because getting the RAM requirement handled better was my main concern :-) , e.g. we have a factor of about 2 between the required RAM for x86 CPUs and ARM CPUs for one application. While the "speed up factor" for tweaking the runtime estimates especially for GPUs might not be ideal, it seems to work kind of reasonably well at least for our project, E@H. But that's a different issue. Cheers HB ----------------------------------------------------------------- Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) From: Richard Haselgrove <[email protected]> To: Heinz-Bernd Eggenstein <[email protected]>, BOINC Developers Mailing List <[email protected]>, Date: 07/23/2013 04:01 PM Subject: Re: [boinc_dev] RAM requirent depending on plan class I think we need to be careful about the scoping validity of data, and we haven't always been in the past. In this particular case, I think that it's a reasonable assumption that the RAM requirements of an application (again in the BOINC terminology) on one platform have a deterministic relationship with the RAM requirements on other platforms. All of that is knowable by the project team, and suitable for implementation on the server. But I think you've chosen a poor example with the CPU-GPU speed relationship. There is no necessary or deterministic relationship between the speed of a GPU, and the speed of the CPU of the host it's mounted in (and to confuse matters further, there's no necessary relationship between the speeds of two different GPUs in the same host). The current code assumes (as a starting point) that a generic GPU is 10x the speed of the associated CPU: I suspect that this assumption - along with a sub-optimal choice of plan_class by the server - is the underlying cause of a recent report of 'EXIT_TIME_LIMIT_EXCEEDED' errors at SETI Beta. http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2008 From: Heinz-Bernd Eggenstein <[email protected]> To: BOINC Developers Mailing List <[email protected]> Sent: Tuesday, 23 July 2013, 12:54 Subject: [boinc_dev] RAM requirent depending on plan class Dear all, I'd like to hear comments on the following problem/idea: For Android on ARM, we at E@H have optimised our science app to require less RAM than our regular CPU app versions for x86 CPUs. OTOH, we would like to have only one application (in the BOINC terminology) for all CPU platforms, so only one suite of work generators, validators etc is needed and x86 and ARM app versions get the same tasks and can even cross-validate against each other, which we think is good. But as the memory requirements are associated to the work unit, we have to use the maximum value for all the different app versions/ plan classes. IMHO the situation is somewhat similar to the execution speed differences for different plan classes that cannot be fully modelled by the BOINC benchmark results (e.g. for CPU-GPU comparison) and I understand that the solution for this was a scaling factor that can be configured with plan classes to let the scheduler know that results are computed faster by a certain factor for a particular plan class compared to what BOINC would assume otherwise. Would it be feasible/a good idea to also have a configurable scaling factor for RAM requirements, perhaps ?? I think many projects will find that optimising for RAM size is important for Android. Cheers HB ----------------------------------------------------------------- Heinz-Bernd Eggenstein Max Planck Institute for Gravitational Physics Callinstrasse 38 D-30167 Hannover, Germany Tel.: +49-511-762-19466 (Room 037) _______________________________________________ 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. _______________________________________________ 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.
