(for many platforms) from samples/example_app/bin
- make_project: change name of example app from uppercase to example_app.
- update_versions: allow version numbers to not have decimal points
- sample work generator: make app name and template files
command-line options;
default to "example_app", "example_app_in.xml", "example_app_out.xml"
svn path=/trunk/boinc/; revision=22667
- If the scheduler doesn't have any app versions for resource type X,
it includes an element <no_X_apps>1</no_X_apps> in the reply msg
(e.g., <no_cpu_apps>1</no_cpu_apps>)
- The client parses and stores these flags,
and doesn't ask a project for work for a resource
if the project doesn't have app versions for it.
Apparently I started this change in [19375] (October 2009)
and forgot to finish it.
svn path=/trunk/boinc/; revision=22661
"accelerate GPU tasks by dedicating a CPU to each one".
Enable this by putting
$accelerate_gpu_apps_pref = true;
in html/project/project.inc
svn path=/trunk/boinc/; revision=22657
size information when it is in a minimized state.
- MGR: Fix the close dialog issue on wxGTK, apparently there is a
hidden flag that governs the handling of the GTK callback
function. Fixes#962 (Thanks for the patch cli)
clientgui/
DlgAdvPreferencesBase.cpp
DlgEventLog.cpp
DlgItemProperties.cpp
svn path=/trunk/boinc/; revision=22635
where being omitted from query strings.
This is incorrect.
For example, suppose you have an app version with nonempty plan_class,
then you try to add a version with no plan class.
The query would omit the "and plan_class = ''"
so it would match the existing app version and not add a new version.
Reported by Rytis.
Hopefully this won't break anything.
svn path=/trunk/boinc/; revision=22616
Old: job scheduling has 2 phases.
In the first phase (schedule_cpus()) we make a list of jobs,
with deadline-miss and high-STD jobs first.
Keep track of the RAM used,
and skip jobs that would exceed available RAM.
Stop scanning when the # of CPUs used by jobs in the list
exceeds the # of actual CPUs.
In the 2nd phase (enforce_schedule()), we add currently running jobs
(which may be in the middle of a time slice) to the list,
and reorder to give priority to such jobs,
and possibly also to multi-thread jobs.
We then run and/or preempt jobs, keeping track of RAM used.
Problems:
- suppose we add an EDF 1-CPU job to the list, then a MT job.
We'll stop at that point because #CPUs is exceeded.
But enforce_schedule() won't run the MT job,
and CPUs will be idle.
- Because the list may be reordered, skipping jobs based
on RAM is not correct, and may cause deadlines to be missed.
New:
- when making the job list, keep track of #CPUs used
by MT jobs and non-MT jobs separately.
Stop the scan only if the non-MT count exceeds #CPUs.
This ensures that we have enough jobs to use all the CPUs,
even if the MT jobs can't be run for whatever reason.
- don't skip jobs because of RAM usage
- skip MT jobs if the MT CPU count is at least #CPUs
Notes:
- ignoring RAM usage in phase 1 can cause idleness in some cases,
e.g. suppose there are 4 GB of RAM and the list has
jobs that use 3 GB, but there are also some jobs that use 1 GB.
I'm not sure how to fix this.
- Maybe the 2-phase approach is not a good idea.
We did it this way for efficiency,
so that we don't have to recompute the job list
each time a job checkpoints.
But this is probably not a concern,
and I like the idea of a simpler approach,
e.g. reducing the policy to a single comparison function.
svn path=/trunk/boinc/; revision=22615
- scheduler: improve the deadline check mechanism slightly.
When updating "estimated delay" (a rough measure of how long
a resource is saturated with high-priority work)
take into account the # of instances used by the job,
and the # of total instances
svn path=/trunk/boinc/; revision=22612
If set, the feeder doesn't read jobs into shmem,
and the scheduler doesn't send jobs.
Intended for use when a project wants to process
a backlog of completed jobs and not issue more.
svn path=/trunk/boinc/; revision=22601
My change of 1 Oct ([22440]) required that such jobs
be processed with 64-bit apps,
on the assumption that 32-bit apps have a 2 GB user address space limit.
However, it turns out this limit applies only to Windows
(kernel and user mode share the 4GB address space; each gets half).
On Linux, the split is 3GB user / 1 GB kernel.
On Mac OS X, user mode and kernel mode have separate address spaces,
each of them 4 GB.
svn path=/trunk/boinc/; revision=22599
They can be determined implicitly by WUs/results,
or explicitly in the <app> record.
If you do neither, the app is ignored.
svn path=/trunk/boinc/; revision=22591
David Anderson