-
Notifications
You must be signed in to change notification settings - Fork 452
DevProjects
BOINC consists of several areas, each with some required technical skills:
| Area | Skills needed |
| Client | C++, Unix and Windows system programming |
| Desktop GUI | C++, WxWidgets, GUI and graphical design, UI/UX |
| Android GUI | Java, Android SDK, UI/UX |
| Server programs | C++, Unix system programming, database design, MySQL |
| Web features | HTML, CSS, PHP, web design, usability, database design, MySQL |
| Unix build system | autoconf, automake, other GNU tools |
The University of California holds the copyright on all BOINC source code. By submitting contributions to the BOINC code, you irrevocably assign all right, title, and interest, including copyright and all copyright rights, in such contributions to The Regents of the University of California, who may then use the code for any purpose that it desires.
There are several ways to get tasks to work on:
- Read the list of proposed projects on this page. (Note: please do not add items to this list; suggest new items in the boinc_dev email list.)
- Scan the BOINC bug database for unresolved bugs or feature requests.
- Scan the BOINC message boards for ideas.
Once you pick out a task:
- Look at the source code and think about how you would implement the task.
- Read about the BOINC software and development process.
- Communicate with the developer community (via the boinc_dev email list or github issues), and reach agreement on exactly what you're going to do and how. Don't start coding until you do this.
Submit your work as a pull request on github, so that the developer community can evaluate it and possibly merge it.
The BOINC Android GUI needs a few enhancements; these are listed here.
- Change the sample project-specific prefs code (html/project/project_specific.prefs.inc) to use the object-oriented structure used for general prefs (html/inc/prefs.inc).
- Change the prefs code to use simplexml() for XML parsing; simplify the code in general.
- Add a Reset button to prefs (both general and project)
- Add a timezone setting to the user prefs and convert time to this timezone (tricky part is daylight savings time) or use a browser setting (if available) when displaying time.
- In the forums, provide an interface for moderators to hide a lots of posts at once (with checkboxes and a button)
The following need to be evaluated:
- Change default Q&A page to refer BOINC-specific questions to BOINC web site. #603
- Convert team name HTML and team description to BBcode. #604
- Add new profile features: #609
- list of recent posts and threads this person created, on this and other projects.
- other features from social networking sites, e.g. recent posts by your friends.
- Add ‘referral' mechanism: new user creates account, enters email of ‘referrer' (or goes to URL that has it embedded). Give referrer a fraction of credit (or a 1-time bonus). List referrals on user page (show only those still active). Add new referral table to DB.
- Create Makefiles and project files to build the sample applications using MinGW and Dev-C++.
- Write example FORTRAN application and Makefiles/ project files.
- Investigate the crlibm library for generating identical results across processors (or at least reducing the number of cases for HR).
- Implement a mechanism where the client can ask apps to checkpoint.
- Use modern process-grouping mechanisms (e.g. Unix process groups).
- Change prefs from "if CPU load > X, suspend works" to "if CPU load is X, use N-X CPUs".
- Let use specify an airport code. Fetch weather data from METAR for that airport. Suspend computing if temperature goes above X.
- Do Whetstone benchmarks in a way that uses processor features such as SSE3 if available. This is done for Android (Neon, VFP); do it for x86 also.
- Keep track of the statistics of how long it takes to upload files, and to report results. Use that info to improve compute deadlines (e.g., subtract the 2 sigma point for both).
- Client monitors total CPU usage, limits its own CPU usage so that total is < 100%.
- Monitor working-set size of non-BOINC apps; don't allow total to exceed physical RAM. This could eliminate the need for memory-usage preferences. Note: this might be tricky because parts of a process's working set is shared with other processes. Some study is needed to figure out the best approach.
- Use multiple disks. This would increase available space, and (if slot dirs spread across disks) would allow I/O-intensive apps to run more efficiently. Would have to remove assumption that project dir is ../../projects/X relative to slot.
- Have the core client sense CPU temperature and throttle CPU if it goes too high. (Code for sensing temperature is already done for Mac.) Open-source software for collecting sensor data (on Linux) is available.
- Windows: get proxy config info directly from the OS.
- Integrate BitTorrent (or libtorrent) with the core client.
- Log result start/ends (for use by 3rd-party software like BoincView).
- Check if host is configured to go into Standby mode after X idle minutes. If so, ask user if they want to let BOINC run for X minutes, then go into standby right after that.
- Make it easy for teams to offer a client download that features their skin, and pre-register the user on that team for any projects he attaches to. #610
- If using an AMS, put link to AMS (or user page) in sys tray popup, elsewhere.
- Reimplement the BOINC Manager so that it is:
- Configurable via an XML file
- Skinnable via CSS
- nicer-looking than the WxWidgets version
- Show weekly/monthly transfer totals.
- The "select language" dialog should show only languages with translations.
- Add support for parallel applications: try to schedule all the jobs in a batch more or less simultaneously.
- Implement a mechanism so that server software detects incompatible database format.
- XML stats: add lat/long to user record?
- Enhance (or rewrite) the automated integration testing of the server components (see existing: https://github.com/BOINC/boinc-server-test). Features that need to be added: a. Test multiple project configurations (default versus GDPR enabled project) using a shared suite of tests and per configuration tests a. Tests and configurations should be stored in the main BOINC repository (easier to add new tests alongside new code) a. Needs to run on Travis CI Ubuntu image
- Integrate GTest Framework into main BOINC repository. Main difficulty is to merge the autoconf based build system with the cmake system gtest uses. See existing approaches in PR#2443, PR#2457, Branch cb_gtest_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 extensive changes to the client, scheduler, and RPC protocol.
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).
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.
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. We have some ideas on how to prioritize batches and prioritize jobs. Complete these designs and implement them.
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.
Details are here.
Currently, when the scheduler sends a job to the client, the job has a fixed deadline. If the job hasn't been completed and reported to the scheduler by then, the server will generate a new instance the job. In some cases this is wasteful. If the client is 90% finished with the job by the deadline, it may be better to let it finish than to create a new instance. The proposal, in general terms:
- Have the client report the status (fraction done and elapsed time) of in-progress jobs.
- Allow the scheduler to extend the deadlines of jobs under some conditions.