| 13 | | Easy: |
| 14 | | * Create Makefiles and project files to build the sample applications using MinGW and DevC++. |
| 15 | | Medium: |
| 16 | | * Write example FORTRAN application and Makefiles/ project files |
| 17 | | Hard: |
| 18 | | * Write an example compound application (and suggest API revisions to make this easier). |
| 19 | | * Investigate the crlibm library for generating identical results across processors (or at least reducing the number of cases for HR). |
| 20 | | * Java support: core client checks for the existence of JVM, reports version to scheduler. Write Java wrapper (runs JVM, gives it jar files). Note: Sztaki has already done some part of this. |
| 21 | | * Same, .NET |
| 22 | | * Distributed Python: Borrow or invent a notation for master/slave execution in Python. Develop a system that implements this on BOINC, i.e., creates WUs and applications, and harvests the results. |
| | 13 | (Requires advanced knowledge of PHP, HTML, and MySQL) |
| 24 | | == Core client == |
| 25 | | Medium: |
| 26 | | * Add a preferences for total download and upload in a month (many Australian ISPs have monthly limits), or per X hours of processing time (see email from Kevin Reed). |
| 27 | | * Don't enforce RAM limits unless free RAM is low |
| 28 | | * GUI RPC to tell apps to checkpoint and quit. |
| 29 | | Hard: |
| 30 | | * Have the core client sense CPU temperature and throttle CPU if it goes too high. Open-source software for this (on Linux) is at http://www.lm-sensors.org/. |
| 31 | | * Windows: get proxy config info directly from the OS |
| 32 | | * After an applications exits or is killed (for whatever reason) make sure (after a few second delay) that its subprocesses are gone too. Don't restart the job until this happens. Unix: use process groups and killpg(). |
| 33 | | * More generally: make a better state machine for shutting down apps: tell them to checkpoint, wait a little, tell them to quit, clean up straggler processes. |
| 34 | | * Same, but for suspend: if we tell a client to suspend and it's still using |
| 35 | | lots of CPU after a few seconds, abort it (or something). |
| 36 | | * Integrate !BitTorrent ([http://www.rasterbar.com/products/libtorrent/ libtorrent]?) with the core client. |
| 37 | | * Do potentially slow RPCs and other tasks (such as computing disk usage) in a separate thread. |
| 38 | | * Log result start/ends (for use by 3rd-party software like !BoincView). |
| 39 | | * Prevent disk space usage from exceeding user preferences, and enforce resource shares, with file deletion according to project policy. |
| 40 | | * Make messages of class MSG_USER_ERROR translatable. |
| 41 | | * Vista: if get 'about to shut down' msg from OS, stop apps immediately (don't tell them to checkpoint). Investigate. |
| 42 | | * XML stats: add lat/long to user record? |
| 43 | | == BOINC Manager == |
| 44 | | Easy: |
| 45 | | * If using an AMS, put link to AMS (or user page) in sys tray popup, elsewhere |
| 46 | | Hard: |
| 47 | | * Properties pages for projects, jobs |
| 48 | | * Turn off alerts (Rom's working on this) |
| 49 | | * Have the Manager do RPCs in a separate thread. |
| 50 | | == Server/Back End == |
| 51 | | Medium: |
| 52 | | * When using HR, if the scheduler has sent one result of a WU using a particular app version, it should use the same app version for other results from that WU. |
| 53 | | Hard: |
| 54 | | * Implement a mechanism so that server software detects incompatible database format |
| 55 | | * Scheduler: implement mechanisms so that server: |
| 56 | | * Attempts to send results from the same WU to hosts with similar speed, so that a fast host doesn't have to wait weeks to get credit. |
| 57 | | * Implement a 'benchmark result' mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results |
| 58 | | == Web features == |
| | 34 | == Applications == |
| | 35 | |
| | 36 | Easy: |
| | 37 | * Create Makefiles and project files to build the sample applications using MinGW and DevC++. |
| | 38 | Medium: |
| | 39 | * Write example FORTRAN application and Makefiles/ project files |
| | 40 | Hard: |
| | 41 | * Write an example compound application (and suggest API revisions to make this easier). |
| | 42 | * Investigate the crlibm library for generating identical results across processors (or at least reducing the number of cases for HR). |
| | 43 | * Java support: core client checks for the existence of JVM, reports version to scheduler. Write Java wrapper (runs JVM, gives it jar files). Note: Sztaki has already done some part of this. |
| | 44 | * Same, .NET |
| | 45 | * Distributed Python: Borrow or invent a notation for master/slave execution in Python. Develop a system that implements this on BOINC, i.e., creates WUs and applications, and harvests the results. |
| | 46 | |
| | 47 | == Core client == |
| | 48 | (Requires advanced C++ system programming experience) |
| | 49 | Medium: |
| | 50 | * Add a preferences for total download and upload in a month (many Australian ISPs have monthly limits), or per X hours of processing time (see email from Kevin Reed). |
| | 51 | * Don't enforce RAM limits unless free RAM is low |
| | 52 | * GUI RPC to tell apps to checkpoint and quit. |
| | 53 | Hard: |
| | 54 | * Have the core client sense CPU temperature and throttle CPU if it goes too high. Open-source software for this (on Linux) is at http://www.lm-sensors.org/. |
| | 55 | * Windows: get proxy config info directly from the OS |
| | 56 | * After an applications exits or is killed (for whatever reason) make sure (after a few second delay) that its subprocesses are gone too. Don't restart the job until this happens. Unix: use process groups and killpg(). |
| | 57 | * More generally: make a better state machine for shutting down apps: tell them to checkpoint, wait a little, tell them to quit, clean up straggler processes. |
| | 58 | * Same, but for suspend: if we tell a client to suspend and it's still using |
| | 59 | lots of CPU after a few seconds, abort it (or something). |
| | 60 | * Integrate !BitTorrent ([http://www.rasterbar.com/products/libtorrent/ libtorrent]?) with the core client (Janus Kristensen is working on this). |
| | 61 | * Do potentially slow RPCs and other tasks (such as computing disk usage) in a separate thread. |
| | 62 | * Log result start/ends (for use by 3rd-party software like !BoincView). |
| | 63 | * Prevent disk space usage from exceeding user preferences, and enforce resource shares, with file deletion according to project policy. |
| | 64 | * Make messages of class MSG_USER_ERROR translatable. |
| | 65 | * Vista: if get 'about to shut down' msg from OS, stop apps immediately (don't tell them to checkpoint). Investigate. |
| | 66 | * XML stats: add lat/long to user record? |
| | 67 | == BOINC Manager == |
| | 68 | (Requires experience with !WxWidgets GUI toolkit) |
| | 69 | Easy: |
| | 70 | * If using an AMS, put link to AMS (or user page) in sys tray popup, elsewhere |
| | 71 | Hard: |
| | 72 | * Properties pages for projects, jobs |
| | 73 | * Turn off alerts (Rom's working on this) |
| | 74 | * Have the Manager do RPCs in a separate thread. |
| | 75 | == Server/Back End == |
| | 76 | |
| | 77 | (Requires advanced C++/Unix system programming experience) |
| | 78 | |
| | 79 | Medium: |
| | 80 | * When using HR, if the scheduler has sent one result of a WU using a particular app version, it should use the same app version for other results from that WU. |
| | 81 | Hard: |
| | 82 | * Implement a mechanism so that server software detects incompatible database format |
| | 83 | * Scheduler: implement mechanisms so that server: |
| | 84 | * Attempts to send results from the same WU to hosts with similar speed, so that a fast host doesn't have to wait weeks to get credit. |
| | 85 | * Implement a 'benchmark result' mechanism: every host runs a benchmark result per app version, and the CPU time determines credit/CPU for future results |
| | 86 | |
