Commit Graph

5 Commits

Author SHA1 Message Date
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