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.
