This change has had a couple of weeks to shake down, and in general seems to be working well. However, one unanticipated problem surfaced at AQUA last night, and could possibly use a refinement.
AQUA had a CUDA app installed, but dormant. They applied the server update for this issue, and I was able to de-select CUDA: my hosts are now receiving the <no_cuda>1</no_cuda> flag in server scheduler replies, and show 'blocked by prefs' in [wfd]. AQUA has now un-installed the old CUDA app, and - as intended - the CUDA preference selection is no longer displayed on users' accounts. But users who did not manually de-select CUDA in their preferences before the control was hidden do not have CUDA work fetch inhibited - BOINC keeps asking, and there's no way to stop it, which is the problem we were trying to avoid in the first place. Suggestion: If there is an available app_version for a resource, reflect the user preference in sched_reply (as now). If there is *no* installed app_version, always return the 'inhibit' flag for that resource. Special case: if there are no available installed applications *at all* (say the user requested work just as the project were updating the installed apps - though one would have expected the scheduler to be switched off during that process), return flags allowing just one resource (probably CPU) to keep polling for work, so the host retains some minimal level of contact with the project and will detect when apps are available again. Users who supply their own (uninstalled) app via anonymous_platform also need to over-ride the fetch inhibition for resources they have specified in app_info.xml Reference to AQUA report: http://aqua.dwavesys.com/forum_thread.php?id=297 >I agree. I'll do this soon > (just the "no CPU" and "no GPU" prefs for now). > -- David > > Richard Haselgrove wrote: >> Following on from my previous thought, it seems that we aren't paying >> enough attention to the scope of some of these settings. >> >> An XML entity has two different scopes: >> >> a scope for the DEFINITION >> a scope for the VALUE >> >> Many BOINC preferences are global for both definition and value. They >> tend to be stored in prefs.xml (global or override). >> >> Other preferences are project-specific for both definition and value, >> like the screen-saver controls Nicolas reminded us of . They live in >> account.xml and client_state.xml. >> >> But there's a third class, with a global definition scope but a project >> value scope, which seems to me to be under-utilised. In fact, it has only >> one member: resource share. >> >> I propose that we examine the recent resource additions, and consider >> whether more of them should be moved into the middle scope (global def, >> project value). Use/don't use CPU/GPU is an obvious place to start, but >> others might be considered: suspend (CPU/GPU) while in use might be >> another candidate - different project apps interfere with the desktop to >> different degrees, and I might be willing to let GPUGrid, for example, >> run a CUDA app while I'm active, but not willing to run an AQUA CUDA app. >> _______________________________________________ >> 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.
