(manage_privileges and get_output.php).
From Nico Schlitter.
- change things so that
make_project --test_app
will produce input/output templates that are compatible
with the remote job submission tools
svn path=/trunk/boinc/; revision=24774
Tells multicore apps how many cores to use.
The --nthreads command line arg to the app is now deprecated
though we'll keep it around for the time being.
svn path=/trunk/boinc/; revision=24708
- web: show BBCode info in the same page, rather than target=new.
On Firefox, this opens a new tab but doesn't switch to it,
which makes it look like nothing happened.
svn path=/trunk/boinc/; revision=24622
parsing cc_config.xml
- client: if an <exclude_cpu> element in cc_config.xml
specifies a nonexistent app, show an error msg with
a list of existing app names
- web: increase the default mem limit from 64MB to 256MB
TODO: change user_hosts.php to show N at a time
svn path=/trunk/boinc/; revision=24593
this is to support SETI@home, which ran out of result IDs
and changed the DB field type to int unsigned.
Note: eventually I'll make this change official
and change the .h types as well.
- web: put <apps_selected> tags around <app_id> elements
in project-specific prefs.
svn path=/trunk/boinc/; revision=24555
(e.g. when editing it via the Manager).
Include only the GPUs that were specified in the original cc_config.xml,
not those detected by the client.
- client: fix bug that failed to require authorization for
GUI RPCs that are supposed to be authorized
- client: report parse errors in acct_mgr_url.xml and acct_mgr_login.xml
- fix compile warnings
- user web: in sample project_specific_prefs.inc,
get app names from the DB instead of listing them in the PHP code.
svn path=/trunk/boinc/; revision=24518
are assumed to be for NVIDIA GPU apps;
plan class names containing 'ati' are assumed to be for AMD GPU apps.
Clauses for 'nvidia' were missing in a couple of places.
svn path=/trunk/boinc/; revision=24512
says whether the client is using account-based sandboxing.
Needed by vboxwrapper.
- web: don't show authenticator in Your Account page.
The problem with authenticators is that if a bad guys gets yours,
they can log in to your account even if you change your password.
Eventually we should not use them at all
(i.e. in cookies and sent to client).
- make_project: copy python stuff (e.g. bin/start) for web-only projects;
generate appropriate project.readme file for web-only projects.
svn path=/trunk/boinc/; revision=24447
(in sched_customize.cpp)
the flops_scale argument is intended to express the
GPU efficiency (actual/peak).
Pass appropriate values.
svn path=/trunk/boinc/; revision=24405
for when the job completed successfully but
one or more output files had permanent upload failures.
Show this state in web interfaces.
- sample_work_generator: check return value of count_unsent_results(),
so that we don't generate infinite work if there's a DB problem
- web: RSS feed shows news items from last 90 days, rather than 14
svn path=/trunk/boinc/; revision=24377
in the presence of GPU exclusions.
The problem was in the job-selection phase,
which picks enough jobs to use all devices.
It was ignoring GPU exclusions, so for example on
a 2 GPU system it could pick 2 jobs from a project
for which 1 GPU is excluded,
and as a result 1 GPU would be idle.
Solution: during job selection,
keep track of GPU usage on a per-instance basis.
Select a job only if it can run on a non-excluded GPU.
- client: in computing ncprocs_excluded (which is used in
work fetch policy) don't count exclusions of non-existent devices
svn path=/trunk/boinc/; revision=24316
where work fetch didn't work right in the presence of
multiple GPUs and <exclude_gpu> config options.
For example: suppose:
- you have 2 GPUs and 2 projects
- Project A is excluded from GPU 1
- you have lots of jobs for project A
Then the client won't try to fetch jobs from project B.
The problem had 2 parts:
a) round-robin simulation wasn't taking GPU exclusions into account.
In the above example, it would think that both GPUs had jobs.
I fixed this by computing the # of GPUs from each project
is excluded, and using this in the RR simulation.
b) Once this was done, I needed to make the client
request GPU jobs from project B rather than project A.
I did this with following policy:
If a project has excluded GPUs of a given type,
and has a runnable job of that type,
don't ask it for more work of that type.
Notes:
- the policy in b) is crude, and it means that work-buffer
preferences are ignored in some cases.
- neither a) nor b) takes into account app-level exclusions.
I could fix both of these with a lot of work,
but I'd rather move to a model in which dissimilar GPUs
are modeled as different resources,
which would remove the need for the <exclude_gpu> mechanism
in the first place.
- web: remove extraneous ) at end of button tooltips
svn path=/trunk/boinc/; revision=24312
but we currently do not expose a way in get_project_config to determine
that a UI should prompt for one. Add a <invite_code_required/> tag
if the project is only accepting new accounts by invitation.
html/user/
get_project_config.php
svn path=/trunk/boinc/; revision=24300
and other operations.
You can now designate a user as "manager" for a particular app.
They can then:
- control job-submit permissions for that app
- deprecate/undeprecate versions of the app.
- abort jobs for that app
You can also designate a user a manage for the project.
They can then edit permissions and quotas,
as well as performing the app-specific functions for all apps.
This is described here:
http://boinc.berkeley.edu/trac/wiki/MultiUser#Accesscontrol
This required some changes to the DB schema.
svn path=/trunk/boinc/; revision=24250
is a "runtime outlier", i.e. its runtime does
not correspond to the job's rsc_fpops_est.
Runtime outliers are not counted in the statistics for
elapsed time, turnaround time, and peak FLOPs count.
The is intended for applications like SETI@home,
some of whose jobs finish more or less instantly
(this happens if the data contains a lot of interference).
If a host happens to get a bunch of these short jobs,
its statistics will get skewed: in essence, the server
will think that the host is extremely fast,
and will send it too many jobs.
svn path=/trunk/boinc/; revision=24225
the <working_global_preferences> element in
scheduler RPC request
(tells the server that there's an override file).
- account manager RPC: add <working_global_preferences> element,
including the override flag.
- web: add "no time limit" option for forum search
- web: increase show-user-post query limit to 10000
svn path=/trunk/boinc/; revision=24129
- scheduler: when using elapsed time stats to predict runtime,
cap the estimated FLOPS at twice the peak FLOPS;
otherwise, if a host has received a lot of very short jobs
recently, it will get a too-high FLOPS estimate and
will exceed the rsc_fpops_bound limit.
svn path=/trunk/boinc/; revision=24128
David Anderson