1. 07 Jul, 2013 1 commit
  2. 27 Jun, 2013 1 commit
  3. 21 Jun, 2013 1 commit
  4. 17 Jun, 2013 1 commit
  5. 15 Jun, 2013 2 commits
    • David Anderson's avatar
      client: fix bug that delayed work fetch from non-CPU-intensive projects · af8ccfe8
      David Anderson authored
      We were waiting until there was no task for the project
      before asking for another task.
      We should have been waiting until there was no in-progress task.
      af8ccfe8
    • David Anderson's avatar
      client: fix bug that allowed work fetch request while file uploads active · eee2879a
      David Anderson authored
      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.
      eee2879a
  6. 10 Jun, 2013 1 commit
  7. 07 Jun, 2013 1 commit
  8. 22 May, 2013 3 commits
  9. 16 May, 2013 1 commit
  10. 26 Apr, 2013 1 commit
  11. 25 Apr, 2013 1 commit
  12. 08 Apr, 2013 1 commit
  13. 04 Apr, 2013 2 commits
    • David Anderson's avatar
    • David Anderson's avatar
      - client emulator: parse <max_concurrent> in <app> in client_state.xml. · 330a2589
      David Anderson authored
          This gives you a way to simulate the effects of app_config.xml
      - client: piggyback requests for resources even if we're backed off from them
      - client: change resource backoff logic
          Old: if we requested work and didn't get any,
              back off from resources for which we requested work
          New: for each resource type T:
              if we requested work for T and didn't get any, back off from T
              Also, don't back off if we're already backed off
                  (i.e. if this is a piggyback request)
              Also, only back off if the RPC was due to an automatic
                  and potentially rapid source
                  (namely: work fetch, result report, trickle up)
      - client: fix small work fetch bug
      330a2589
  14. 03 Apr, 2013 1 commit
  15. 02 Apr, 2013 1 commit
    • David Anderson's avatar
      - client: major overhaul of work-fetch logic based on suggestions · f6a61fe8
      David Anderson authored
          by Jacob Klein.
          The new policy is roughly as follows:
          - find the highest-priority project P that is allowed
              to fetch work for a resource below buf_min
          - Ask P for work for all resources R below buf_max
              for which it's allowed to fetch work,
              unless there's a higher-priority project allowed
              to request work for R.
          If we're going to do an RPC to P for reasons other than work fetch,
          the policy is:
          - for each resource R for which P is the highest-priority project
              allowed to fetch work, and R is below buf_max,
              request work for R.
      f6a61fe8
  16. 25 Mar, 2013 1 commit
  17. 24 Mar, 2013 1 commit
  18. 22 Mar, 2013 2 commits
  19. 15 Mar, 2013 2 commits
  20. 07 Mar, 2013 3 commits
  21. 05 Mar, 2013 2 commits
  22. 04 Mar, 2013 2 commits
  23. 01 Mar, 2013 2 commits
    • David Anderson's avatar
      - client: in checking reasons for not requesting work, · 5457b6b7
      David Anderson authored
          look at backoff last.
          Otherwise the user can get a misleading message if they
          update a project that's backed off
      5457b6b7
    • David Anderson's avatar
      - client: change work fetch policy to avoid starving GPUs in situations where... · 777f1f11
      David Anderson authored
      - 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.
      777f1f11
  24. 20 Aug, 2012 1 commit
    • David Anderson's avatar
      - client: take GPU exclusions into account when making · 446bc4ca
      David Anderson authored
          initial work request to a project
      - client: put some casts to double in NVIDIA detect code.
          Shouldn't make any difference.
      - volunteer storage: truncate file to right size after retrieval
      
      
      svn path=/trunk/boinc/; revision=26051
      446bc4ca
  25. 18 Aug, 2012 1 commit
  26. 10 Aug, 2012 2 commits
    • David Anderson's avatar
      - client: tweak to the above: never ask for work if buffer > max. · 9fa75d50
      David Anderson authored
          This is needed to prevent projects that use next_rpc_delay
          from queuing unbounded work.
      
      
      svn path=/trunk/boinc/; revision=26003
      9fa75d50
    • David Anderson's avatar
      - client: when we're making a scheduler RPC · ff1a391c
      David Anderson authored
          for a reason other than work fetch,
          and we're deciding whether to piggyback a work request,
          skip the checks for hysteresis (buffer < min)
          and for per-resource backoff time.
          These checks are there only to limit the rate of RPCs,
          which is not relevant since we're doing one any.
      
          This fixes a bug where a project w/ sporadic jobs specifies
          a next_rpc_delay to ensure regular polling from clients.
          When these polls occur they should request work regardless of backoff.
      
      
      svn path=/trunk/boinc/; revision=26002
      ff1a391c
  27. 06 Aug, 2012 1 commit
  28. 22 Jul, 2012 1 commit