David Anderson wrote: > Good point. I'll add that, though it should be per app, not app version. > Here's a summary of new database items: > > (1) = brand new > (2) = moved from the project config file > (3) = moved from the host table > > Per app: > max jobs in progress (2) > max GPU jobs in progress (2) > max jobs to send per RPC (2) > initial max jobs per day (2) > > Per app version: > mean claimed credit (1) > > Per (host, app version): > mean claimed credit (1) > mean and var elapsed time (1) > error rate (3) > max jobs per day (3) > # of jobs today (3) > mean and var turnaround time (1) > > Any other suggestions?
The "max jobs in progress" and "max GPU jobs in progress" assumes that there are only two types of compute resources. We already have volunteer systems that have a mix of multiple *different* GPUs in single hosts... So for example, how does a host that has: A multicore CPU; An nVidia 9600; An nVidia GTX295; An nVidia Tesla; An ATI whatever slow one; An ATI whatever super fast one... fit into the scheme? Especially so for the Tesla that might not now be the fastest device but it is still a GPU with multi GBytes of very fast RAM and an especially valuable resource for that... Such a hybrid monster might be a rarity at the moment, but they do exist. Much more common will be systems with a slow old GPU paired with a much newer super-fast GPU as people upgrade. Multiple compute resources in a single host will become ever more common... Can the database be made more general now in advance of when examples of multiple resources become more common... Regards, Martin -- -------------------- Martin Lomas m_boincdev ml1 co uk.ddSPAM.dd -------------------- _______________________________________________ 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.
