| 1 | = Google Summer of Code 2013 project ideas = |
| 2 | |
| 3 | == Enhance the BOINC Android GUI == |
| 4 | |
| 5 | The current BOINC Android GUI is functional but not visually appealing, |
| 6 | and it lacks some usability features. |
| 7 | The project is to design and implement improvements to the GUI. |
| 8 | Possibilities includes: |
| 9 | |
| 10 | * Add graphics to the GUI; for example, allow projects to supply |
| 11 | slide-show images illustrating their science. |
| 12 | * Implement mechanism that allow users to smoothly navigate |
| 13 | from the GUI to web-based features on project sites, |
| 14 | as is done on the desktop BOINC GUI. |
| 15 | * Implement the "notices" mechanism that allows project to push |
| 16 | news items to volunteers. |
| 17 | |
| 18 | == Automated testing of BOINC == |
| 19 | |
| 20 | We're in the process of deploying a Jenkins-based automated test system for BOINC. |
| 21 | Help us add unit tests to the BOINC code, |
| 22 | and to design end-to-end tests that exercise the entire system |
| 23 | under a range of use cases and error conditions. |
| 24 | |
| 25 | == Job size matching == |
| 26 | |
| 27 | Some BOINC projects now have applications with versions for GPUs, CPUs, and mobile devices. |
| 28 | The speed of these devices varies by roughly 3 orders of magnitude; |
| 29 | a job that takes 10 minutes to complete on a GPU might take a week to complete on a mobile device. |
| 30 | This disparity is undesirable - we'd like all jobs to take roughly the same amount of time. |
| 31 | To do this, we need a way to generate an appropriate distribution of jobs sizes, |
| 32 | based on a dynamic resource pool, |
| 33 | and we need a scheduling mechanisms that distributes jobs appropriately. |
| 34 | Design and implement these. |
| 35 | |
| 36 | == Accelerating batch completion == |
| 37 | |
| 38 | Volunteer computing resources are unreliable - computers fail, |
| 39 | people uninstall BOINC, and so on. |
| 40 | Roughly 5% of jobs fail or time out. |
| 41 | This means that in a batch of 10,000 jobs, 500 or so will fail. |
| 42 | We retry these (after a delay of a few days) and 25 or so will fail, and so on. |
| 43 | Thus is can take quite a long time to finish the entire batch. |
| 44 | |
| 45 | This problem can be solved by using more reliable computers to handle retries |
| 46 | and jobs at the end of a batch. |
| 47 | Doing so, however, is tricky. |
| 48 | Design and implement a mechanism for doing this. |