Note: Android clients report the Linux kernel version in host.os_version.
A month or two ago we added the Android version,
which can't always be inferred from the Linux version.
This will only work for devices running this new client.
For projects (like Lattice) that assign a WU's HR class when it's created,
we don't want the mechanism that clears the HR class
if there are error results and no in-progress of completed results.
This option suppresses this.
There was a bug where, when you suspend GPU activity,
GPU jobs show as suspended but are not actually suspended.
This was because of recent changes to distinguish GPU and non-GPU coprocs.
Change things so that coprocs are by default GPUs.
If you want to declare a non-GPU coproc in your cc_config.xml,
you much put <non_gpu/> in its <coproc> element.
Tasks and daemons written in PHP are generally run with a command of the form
run_in_ops script.php
The start script would, by default, base log/out/lock/pid filenames
on "run_in_ops".
This forced you to specify the filenames in config.xml, e.g.
<output>script.out</output>
Fix this by skipping the run_in_ops and using the next string
to form default filenames.
The OS version# constraints (os_min_version, os_max_version)
were only supported for Win and Mac.
Make them work for Linux and Android too.
Note: for Android, we get the Linux kernel version.
This isn't the same as the Android version, but it may be enough
When a project is reset, the client deletes all the files from its dir
that BOINC knows about.
However, there may be other files, created by its apps.
On Android, where space is likely to be scarce,
delete these when the project is reset.
Maybe we should do this on all projects.
But we'd need to not to delete user-created files
like app_config.xml, and anonymous-platform stuff
like app_info.xml and the app files.
When using XML plan class spec, the "mt" plan class would
correctly set avg_ncpus, but wouldn't pass a cmdline arg to the app.
So you'd get jobs where BOINC thinks it's using N CPUs,
but it's actually using only one.
I.e. treat miner ASICs as a distinct processor type;
send miner_asic jobs only if the client requests them.
Note: I was planning to do this in a more general way,
in which the scheduler wouldn't have a hard-wired list of processor types.
However, that would be a large code change,
so for now I just added miner_asic to the list of processor types
(nvidia, ati, intel_gpu),
and made various changes to get things to work.
Also: in the job dispatch logic, try to send coproc jobs
before CPU jobs.
That way if e.g. there's a limit on jobs in progress,
we'll preferentially send coproc jobs.
The old scheduler worked as follows:
scan jobs; for each job
get_app_version
do various checks
add_job_to_reply
The check for per-app job limits was in get_app_version,
and the incrementing of per-app job count is in add_job_to_reply.
The new (score-based) scheduler works as follows:
scan jobs; for each job
get_app_version
add to list
sort list by score
scan list; for each job
do various checks
add_job_to_reply
So the limit check (in get_app_version) was ineffective
because it happens before we've incremented counts.
Fix: do the limit check (also) in the "scan list" loop.
Bigger picture: we need to restructure app version selection;
job limit enforcement doesn't belong there any more.
Aargh! My checkin of 31 Aug 2011 causes the client to strip the trailing \n
from the code-signing key; this change affects 7.0+ clients.
This broke the documented protocol for changing code-signing keys,
since signatures for the new key with the trailing \n won't work.
Solution: when you change code-signing key,
you have to sign both the stripped and non-stripped versions
of the new public key.
See http://boinc.berkeley.edu/trac/wiki/CodeSigning
This required a change to the scheduler so that it sends
one signature or the other based on client version
(stripped for 7.0+, else unstripped).
This change is entirely within send_code_sign_key(),
in case you want to update just that.
See http://boinc.berkeley.edu/trac/wiki/PerAppCredit
If enabled (by the <credit_by_app> config flag)
validators will maintain on a per-(app, user, credit type) basis,
and same for teams,
in new DB tables credit_user and credit_team.
This info is displayed in the web site, on user and team pages,
using project-supplied functions to generate the HTML.
Note: update_stats doesn't decay the recent-average values
for per-app credit; I'll add this if needed.
A month or two ago I added code to put user CPID in the project info
exported via GUI RPC, so that GUIs (like BoincTasks) could link
to user pages on stats sites.
However, I completely forgot that the CPID known to the client
(PROJECT::cross_project_id) is the "internal CPID",
while what gets exported to stats is the "external CPID",
which is MD5(internal CPID, email addr).
Solution: include the external CPID in scheduler replies,
store it in the client state file,
and export it in GUI RPCs as PROJECT::external_cpid.
This will eventually work for BoincTasks,
but only after projects update their server software,
and volunteers update their client software.
A "generic" coprocessor is one that's reported by the client,
but's not of a type that the scheduler knows about (NVIDIA, AMD, Intel).
With this commit the following works:
- On the client, define a <coproc> in your cc_config.xml
with a custom name, say 'miner_asic'.
- define a plan class such as
<plan_class>
<name>foobar</name>
<gpu_type>miner_asic</gpu_type>
<cpu_frac>0.5</cpu_frac>
<plan_class>
- App versions of this plan class will be sent only to hosts
that report a coproc of type "miner_asic".
The <app_version>s in the scheduler reply will include
a <coproc> element with the given name and count=1.
This will cause the client (at least the current client)
to run only one of these jobs at a time,
and to schedule the CPU appropriately.
Note: there's a lot missing from this;
- app version FLOPS will be those of a CPU app;
- jobs will be sent only if CPU work is requested
... and many other things.
Fixing these issues requires a significant re-architecture of the scheduler,
in particular getting rid of the PROC_TYPE_* constants
and the associated arrays,
which hard-wire the 3 fixed GPU types.
Currently the server doesn't know about different client "brands",
e.g. HTC Power to Give, Charity Engine, GridRepublic, etc.,
so there's no way to collect statistics about them.
Changes:
- client: at startup, read a "client brand" string from client_brand.txt
(i.e. branded clients will have to include this file in their installer)
Report this string in scheduler requests.
- scheduler: parse this request element,
and store it in host.serialnum as [BOINC|7.4.2|brand]
Eric J Korpela