Previously, the dir_scan() function didn't distinguish between
- reaching the end of the directory
- errors
It just returned nonzero in either case.
This means that the function that cleans out a slot dir
(client_clean_out_dir())
could potentially return success even though the directory is nonempty.
This could potentially cause the recently-reported problem
where a slot dir contains a VM image from a previous job.
There were two problems:
1) we were sorting before parsing the client state file
(which is where we get project names from)
2) the Win implementation of strcasecmp() wasn't right;
it returned difference but not order.
If set, non-CPU-intensive jobs are exempted from mass suspend
(e.g. suspend CPU, time of day, CPU throttling).
You can still suspend them individually.
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.
On Android, the way we were getting os_version
(Linux version + Android version)
didn't work because get_host_info() was getting called before every
scheduler RPC, and it overwrote the Android version part.
Solution: divide host info into dynamic (disk usage, network info)
and static (everything else).
Computer the static part only at startup.
Also factor the Unix HOST_INFO code into multiple functions.
The following should apply to GPUs but not other coprocs (e.g. miner ASICs):
- "suspend GPUs" command in GUI
- prefs for suspending GPUs
- always removing app from memory when suspended
There's no need for this since the bodies are stored in CDATA.
Doing so causes a bug:
if a notice body contains an entity (like &)
and we get the same notice from an RSS feed,
the 2 notices are treated as separate
since the old copy is unescaped and the new one isn't.
This leads to confusion;
e.g. if you do "read config files" it will look for cc_config.xml
in the new directory, not find it, and set default options.
Also, log files end up in old directory.
Also, gui_rpc_auth.cfg will be in new directory,
and the Manager won't look there.
- get_project_config.php: if project supports LDAP,
advertise this to the client.
- Manager: if project supports LDAP, say "Email address or LDAP ID"
in Attach Project wizard,
and don't do email address validation.
- lookup_account GUI RPC (client side): if passing an LDAP ID,
don't lowercase it, and don't hash passwd
- lookup_account GUI RPC (server side): if passing an LDAP ID,
pass appropriate URL args to Web RPC
- lookup_account Web RPC: in LDAP case, pass "ldap_auth" arg,
and pass "ldap_uid" and "passwd".
Handle these appropriately.
Add optional <priority>N</priority> to <task> element to job.xml.
Lets you specify the process priority of the task;
in particular, task can run at high priority.
Apparently this is needed to make bitcoin ASIC apps perform well.
* the host has GPUs from two different vendors with different OpenCL platforms (e.g., NVIDIA and AMD), and
* the second platform queried has more GPUs than the first one, and
* the requested GPU is a higher numbed one in the second platform.
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.
David Anderson