On some hosts, gpu_active_frac may be much less than active_frac
(i.e., GPUs may be available much less than CPUs).
Use gpu_active_frac in the following places:
- scheduler: in estimating the elapsed time of jobs,
to decide whether they can meet deadline
- scheduler: in computing the effective speed of a (host, app version),
when deciding what size class it belongs to
- size_census: in computing effective speed of (host, app versions)
(Previously, we were just using active_frac in all these cases)
- gpu_active_frac is the fraction of time GPU use is allowed
while the client is running.
Previously the client reported it but we weren't storing it in the DB.
We may need it in the future for batch scheduling logic.
- fix a crashing bug in scheduler
- client: minor message tweak
The web RPCs done by the client during project attach
(lookup_account, create_account)
have an email address and password hash in their request.
Network sniffers could potentially see these,
so we should use HTTPS for these RPCs if possible.
However, not all BOINC projects have SSL-enabled web servers.
So I did the following:
- Change get_project_config.php to return an additional
<web_rpc_url_base> element.
This is SECURE_URL_BASE (if specified in the project's
project.inc config file) or, if not, the master URL.
- This new element is parsed into the PROJECT_CONFIG structure.
- In calls to create_account and lookup_account,
the Manager uses PROJECT_CONFIG::web_rpc_url_base
if it's available, else the master URL.
So, the new Manager/client uses HTTPS for RPCs to projects
that have updated their get_project_config.php,
and specify a SECURE_URL_BASE with https:// prefix.
Android note: I added code to parse the new config element,
but didn't change the higher-level code;
Joachim will need to do this.
The batch query call used by Condor (query_batch_set(), in the C++ API)
returned info about all the jobs in the set of batches,
even those that hadn't changed.
This is potentially inefficient - a query might return info
about 10,000 jobs, only a few (or none) of which have changed state
since the last call.
Solution: add a "min_mod_time" parameter to the call.
Only jobs that have changed state since that time are reported.
Also, add a "server_time" field to the return,
giving the current time on the server
(in case there's clock skew between client and server)
Also, fix some text scrambling introduced in previous checkin;
there must have been a gremlin in my vim.
- allow overcommitment by > 1 CPU.
E.g. If there are two 6-CPU jobs on an 8 CPU machine, run them both.
- Prefer MT jobs to ST jobs in general.
When reorder the run list (i.e. converting "preliminary" to "final" list),
prefer job J1 to J2 if:
1) J1 is EDF and J2 isn't
2) J1 uses GPUs and J2 doesn't
3) J1 is in the middle of a timeslice and J2 isn't
4) J1 uses more CPUs than J2
5) J1's project has higher scheduling priority than J2's
... in that order.
4) is new; it replaces the function promote_multi_thread_jobs(),
which did something similar but didn't work in some cases.
- add a PHP interface for lookup_account()
- PHP interfaces return error number as well as message
(messages change; numbers don't)
- using symbolic error codes instead of hardwired numbers in PHP code
- add delete button
- show # of badges assigned
- don't use separate head/tail function are admin pages
- add badge assign task for new projects
- turn on db_dump, update_uotd, update_forum_activities,
update_profile_pages, notify for new projects
- the default badges (defined in ops/badge_assign.php) are now
based on RAC percentile (top 1%, 5%, and 25%) rather than plain RAC.
- RAC percentile badges are now granted for teams as well as users;
show badges in team page.
- move badge utility functions to inc/util_ops.inc
David Anderson