Commit Graph

11 Commits

Author SHA1 Message Date
David Anderson eee2879a57 client: fix bug that allowed work fetch request while file uploads active
A while back we added a mechanism intended to defer work-request RPCs
while file uploads are happening,
with the goal of reporting completed tasks sooner
and reducing the number of RPCs.
There were 2 bugs in this mechanism.
First, the decision of whether an upload is active was flawed;
if several uploads were active and 1 finished,
it would act like all had finished.
Second, when WORK_FETCH::choose_project.cpp() picks a project,
it sets p->sched_rpc_pending to RPC_REASON_NEED_WORK.
If we then decide not to request work because an upload
is active, we need to clear this field.
Otherwise scheduler_rpc_poll() will do an RPC to it,
piggybacking a work request and bypassing the upload check.
2013-06-14 22:40:43 -07:00
David Anderson c6d79d1172 client: fix bug that could cause client to never contact project
if a project sends us <no_rsc_apps> flags for all processor types,
then by default the client will never do a scheduler RPC to that project again.
This could happen because of a transient condition in the project,
e.g. it deprecates all its app versions for a while.

To avoid this situation, the client now checks whether the no_rsc_apps flags
are set for all processor types.
If they are, it clears them all.
This will cause work fetch to use backoff,
and the client will occasionally contact the project.
2013-05-17 10:25:03 -07:00
David Anderson 64d7fa3474 - client: more fixes to GUI RPC addition.
Also, replace get_project_dir() with a memoized member function of PROJECT
2013-04-18 13:57:33 -07:00
David Anderson 68331492ac - client: Avoid showing too-old stats in GUI.
Trim old credit statistics on each GUI RPC
    as well as each scheduler reply.
2013-04-17 01:25:24 -07:00
David Anderson 24e8133e4b - tabs -> spaces 2013-04-02 17:23:37 -07:00
David Anderson 24b62b58a8 - client emulator: fix crash if you have active tasks of
non-CPU-intensive projects
2013-03-07 11:28:43 +01:00
David Anderson 952a495fb7 - client: add "client app configuration" feature; see
http://boinc.berkeley.edu/trac/wiki/ClientAppConfig
    This lets users do the following:
    1) limit the number of concurrent jobs of a given app
        (e.g. for WCG apps that are I/O-intensive)
    2) Specify the CPU and GPU usage parameters of GPU versions
        of a given app.
    Implementation notes:
    - max app concurrency is enforced in 2 places:
        1) when building the initial job run list
        2) when enforcing the final job run list
        Both are needed to avoid possible starvation.
    - however, we don't enforce it during RR simulation.
        Doing so could cause erroneous shortfall and work fetch.
        This means, however, that work buffering will not work
        as expected if you're using max concurrency.
2013-03-04 15:20:32 +01:00
David Anderson aa31777003 - client: if a project has 64 or more ready-to-report tasks,
report them.
    64 is chosen a bit arbitrarily, but the idea is to
    limit the number of tasks reported per RPC,
    and to accelerate the reporting of small tasks.
2013-03-04 15:04:51 +01:00
David Anderson 777f1f11e8 - client: change work fetch policy to avoid starving GPUs in situations where GPU exclusions are used. - client: fix bug in round-robin simulation when GPU exclusions are used.
Note: this fixes a major problem (starvation)
    with project-level GPU exclusion.
    However, project-level GPU exclusion interferes with most of
    the client's scheduling policies.
    E.g., round-robin simulation doesn't take GPU exclusion into account,
    and the resulting completion estimates and device shortfalls
    can be wrong by an order of magnitude.

    The only way I can see to fix this would be to model each
    GPU instance as a separate resource,
    and to associate each job with a particular GPU instance.
    This would be a sweeping change in both client and server.
2013-03-01 15:31:41 +01:00
David Anderson e79d3ea4c8 - client: change the way project disk share is computed.
- Allow projects to report "desired disk usage" (DDU).
        If the client learns that a project wants disk space,
        it can shrink the allocation to other projects.
    - Base share computation on DDU rather than disk usage.
    - Introduce the notion of "disk resource share".
        This is defined (somewhat arbitrarily) as resource share
        plus 1/10 of the largest resource share.
        This is intended to ensure that even zero-share projects
        get enough disk space to store app versions and data files;
        otherwise they wouldn't be able to compute.
- server: use host.d_boinc_max (which wasn't being used)
    to start d_project_share reported by client.
- volunteer storage: change the way hosts are allocated to chunks.
    Allow hosts to store several chunks of the same file, if needed


svn path=/trunk/boinc/; revision=26052
2012-08-22 04:02:52 +00:00
David Anderson bbfbef0fe8 - client: code cleanup. Move RESULT and PROJECT to separate files
svn path=/trunk/boinc/; revision=25621
2012-04-30 21:00:28 +00:00