Changes between Version 81 and Version 82 of DevProjects

Timestamp:

Apr 9, 2013, 2:28:50 PM (13 years ago)

Author:

davea

Comment:

--

DevProjects

@@ -24 +24 @@
 There are several ways to get tasks to work on:
 
+ * Read the list of proposed projects on this page.
  * Scan the [/query BOINC bug database] for unresolved bugs or feature requests.
- * Read the list of proposed features on this page.
  * Scan the [//dev/ BOINC message boards] for ideas.
 
@@ -40 +40 @@
 so that they can evaluate it and possibly check it in.
 
-== Proposed features ==
+== Major projects ==
 The following development projects are available
 '''(Note: please do not add items to these lists.
 Suggest new items in the boinc_dev email list.)'''
 
-=== High priority ===
+=== Handle heterogeneous GPUs ===
+Currently BOINC requires that all GPUs of a given vendor (NVIDIA, ATI, Intel) be similar,
+and it treats them as a single pool
+(i.e. jobs are not associated with a particular GPU instance).
+This model has a number of drawbacks on machines with multiple different GPUs.
+Change the model so that each GPU is treated separately.
+This will require extensive changes to the client, scheduler, and RPC protocol.
 
- 1. Change the GPU framework.
-  Currently BOINC requires that all GPUs of a given vendor (NVIDIA, ATI, Intel) be similar,
-  and it treats them as a single pool
-  (i.e. jobs are not associated with a particular GPU instance).
-  This model has a number of drawbacks on machines with multiple different GPUs.
-  Change the model so that each GPU is treated separately.
-  This will require major changes to the client, scheduler, and RPC protocol.
- 1. The client's job scheduler has several O(N^2) algorithms,
-  where N is the number of jobs queued on the client.
-  Change these to Nlog(N).
- 1. The scheduler's logic for selecting app versions is clumsy.
-  Replace it with logic that, at the start, selects a version for each (app, resource type)
-  and stores these in an array.
+=== Eliminate O(n!^2) algorithms ===
+The client's job scheduler has several O(N!^2) algorithms,
+where N is the number of jobs queued on the client.
+These cause the client to use lots of CPU when N is large (1,000).
+Change these to Nlog(N).
+
+=== Automated testing of BOINC ===
+
+We plan to deploy a Jenkins-based automated test system for BOINC.
+Help us add unit tests to the BOINC code,
+and to design end-to-end tests that exercise the entire system
+under a range of use cases and error conditions.
+
+=== Accelerating batch completion ===
+
+Volunteer computing resources are unreliable - computers fail,
+people uninstall BOINC, and so on.
+Roughly 5% of jobs fail or time out.
+This means that in a batch of 10,000 jobs, 500 or so will fail.
+We retry these (after a delay of a few days) and 25 or so will fail, and so on.
+Thus is can take quite a long time to finish the entire batch.
+
+This problem can be solved by using more reliable computers to handle retries
+and jobs at the end of a batch.
+Doing so, however, is tricky.
+Design and implement a mechanism for doing this.
+
+=== Improve app version selection ===
+
+The scheduler's logic for selecting app versions is clumsy.
+Replace it with logic that, at the start of a request, selects a version for each (app, resource type)
+and stores these in an array.
+
+== Small and medium-size project ==
+
+=== Enhance the BOINC Android GUI ===
+
+The current BOINC Android GUI is functional but not visually appealing,
+and it lacks some usability features.
+Design and implement improvements to the GUI.
+Possibilities includes:
+
+ * Add graphics to the GUI; for example, allow projects to supply
+   slide-show images illustrating their science.
+ * Implement mechanism that allow users to smoothly navigate
+   from the GUI to web-based features on project sites,
+   as is done on the desktop BOINC GUI.
+ * Implement the "notices" mechanism that allows project to push
+   news items to volunteers.
 
 === Web features ===