There's an initial 'new' device limit of 5 work units per processor core/thread so as to ensure that there are no WU shredders coming aboard [regardless of how big the additional buffer / cache is set]. Soon as a first result is completed / returned hosts can receive up to 80 work units per CPU core/thread up to 32 per host ***. These daily per core limits are to prevent a single device or park cruncher to swallow up the whole feeder stock or to create a mountain of repair/no reply jobs that can only be channeled to known reliable hosts **.

The increment / decrement of the daily quota is per the following rules:

• Reductions of daily core quota by 1 result each for:
  
  
  • All results that return without an immediate error code.
    
  • Error results - Immediately recorded on Result Status page with this status
    
  • Server Aborts (used with great restraint, but automatic if over the deadline)
    
  • User Aborts (for instance for Overdue results)
    
  • Self Aborts (the inexplicable)
    
  • Detaching client from WorldCommunityGrid, which cancels the tasks in the cache immediately upon reattaching.
    
  
  
• Increases of daily quota, doubling up to 80 per core/processor thread daily maximum.
  
  
  • Valid / Invalid Results (Those returned without an instantaneous Error evaluation)
    On 22 April 2013 knreed announced the following change:
    We are changing the logic that controls how many jobs per day a host can get for a given app version. Previously the logic was:
    
    max_jobs_per_day is initialized to 5
    for each job returned successfully, max_jobs_per_day=max_jobs_per_day*2 (up to a max limit)
    for each job returned as an error, max_jobs_per_day=max_jobs_per_day-1
    for each job that is valid, max_jobs_per_day=max_jobs_per_day+1
    for each job that is invalid and if max_jobs_per_day is over the max limit, then max_jobs_per_day=max_jobs_per_day-1
    
    the new logic is:
    max_jobs_per_day is initialized to 5
    for each job returned successfully, max_jobs_per_day=max_jobs_per_day+1 (up to a max limit)
    for each job returned as an error, max_jobs_per_day=max_jobs_per_day-1
    for each job that is valid, max_jobs_per_day=max_jobs_per_day+1
    for each job that is invalid, then max_jobs_per_day=max_jobs_per_day-2
    
    This makes it so that if you don't have at least 50% of your jobs valid, then your daily quota will be reduced. The downside is that it will take longer for people to be able to create large caches.
    
    
    
  Work fetches per device have an assignment capping of 30 per request [as of Jan.30, 2012], to reflect the increasing number of processors in a single device and reduce load on the servers scheduler.

A sample message when having reached quota on a 4 core device:

14/05/2009 22:05:06 World Community Grid Message from server: (reached daily quota of 320 results)

A sample scenario where a device / core got reduced to 1 per day until returning an error-free result:

• 1st Return: + 2
  
• 2nd Return: + 4
  
• 3rd Return: + 8
  
• 4th Return: + 16
  
• 5th Return: + 32
  
• 6th Return: + 64
  
• 7th Return: Maximum for the day less previous completions for the 24 hours UTC period.

The World Community Grid per core/processor thread quota is per day according UTC timekeeping, subject to change as and when shorter tasks or faster devices enter the grid. Multiply this value for a device/host by the number of core/processor threads enable for BOINC to use.

If a device aka host / client has retrieved it's daily quota, the client will be told by the servers to back off from further work requests for the day. In case of quota reductions due error condition, these remain in place until this has been corrected or more valid work is returned [e.g. additional work from cache that gets returned the same day].

The daily maximum is absolute. Post in the BOINC support forum if a greater number is completed within 24 UTC hours or more cores are in a host. The technicians have the ability to enter individual device exceptions and or do quota resets based on documented justification.

** Reliable hosts are those devices that return valid work within 48 hours (2 days) of receipt (3.6 days by exception for Power Mac) and report a multi-day average of 15 good results consecutively. All new devices need to report more than 76 valid results to be in this class. Each good / bad result decrements/increments this rating by 5% minus or plus from the previous running rating. Long running reliable devices do not fall out of this class immediately. I.e., reliable is when the error rate is equal or below 0.2%. A device that has reached a level of 0.1% will on first error be incremented to 0.105%, the next error increasing the value to 0.11025% etc.

*** The daily per core limit of work units and 32 cores will in effect spread the total maximum host results over more cores in a device when there are more. In effect a 64 core device would thus have a quota of half the maximum per day.

Comments/Queries/Fears, open a topical thread in the BOINC support forum. Please keep it consolidated in 1 Quota discussion thread. Will incorporate changes as and when known and confirmed.

Related topics:

Return to Start Here FAQ Index

edit May 28, 2010: Increased quota multiplier from 16 to 32 cores/threads maximum per device/host.