Changes between Version 95 and Version 96 of DevProjects


Ignore:
Timestamp:
Sep 18, 2015, 2:06:34 PM (9 years ago)
Author:
davea
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DevProjects

    v95 v96  
    66
    77|| '''Area''' || '''Skills needed''' ||
    8 || Client || C++, system programming ||
    9 || Desktop GUI || C++, !WxWidgets, GUI and graphical design, usability ||
     8|| Client || C++, Unix and Windows system programming ||
     9|| Desktop GUI || C++, !WxWidgets, GUI and graphical design, UI/UX ||
    1010|| Android GUI || Java, Android SDK, UI/UX ||
    1111|| Server programs || C++, Unix system programming, database design, MySQL ||
    … …  
    3232
    3333 * Look at the source code and think about how you would implement the task.
    34  * Read about the BOINC [wiki:SoftwareDevelopment software] and [wiki:DevProcess development process].
     34 * Read about the BOINC [wiki:SoftwareDevelopment software]
     35    and [wiki:DevProcess development process].
    3536 * Communicate with the area owner,
    3637   and reach agreement on exactly what you're going to do and how.
    … …  
    3940Submit your work (as diffs or files) to the area owner,
    4041so that they can evaluate it and possibly check it in.
    41 
    42 == Major projects ==
    43 
    44 === Handle heterogeneous GPUs ===
    45 
    46 Currently BOINC requires that all GPUs of a given vendor (NVIDIA, ATI, Intel) be similar,
    47 and it treats them as a single pool
    48 (i.e. jobs are not associated with a particular GPU instance).
    49 This model has a number of drawbacks on machines with multiple different GPUs.
    50 
    51 Change the model so that each GPU is treated separately.
    52 This will require extensive changes to the client, scheduler, and RPC protocol.
    53 
    54 === Eliminate O(n!^2) algorithms ===
    55 
    56 The client's job scheduler has several O(N!^2) algorithms,
    57 where N is the number of jobs queued on the client.
    58 These cause the client to use lots of CPU when N is large (1,000).
    59 Change these to Nlog(N).
    60 
    61 === Automated testing of BOINC ===
    62 
    63 Help us add unit tests to the BOINC code,
    64 and to design end-to-end tests that exercise the entire system
    65 under a range of use cases and error conditions.
    66 
    67 === Accelerating batch completion ===
    68 
    69 Volunteer computing resources are unreliable - computers fail,
    70 people uninstall BOINC, and so on.
    71 Roughly 5% of jobs fail or time out.
    72 This means that in a batch of 10,000 jobs, 500 or so will fail.
    73 We retry these (after a delay of a few days) and 25 or so will fail, and so on.
    74 Thus is can take quite a long time to finish the entire batch.
    75 
    76 This problem can be solved by using more reliable computers to handle retries
    77 and jobs at the end of a batch.
    78 Doing so, however, is tricky.
    79 We have some ideas on how to
    80 [PortalFeatures prioritize batches] and [JobPrioritization prioritize jobs].
    81 Complete these designs and implement them.
    82 
    83 === Improve app version selection ===
    84 
    85 The scheduler's logic for selecting app versions is clumsy.
    86 Replace it with logic that, at the start of a request,
    87 selects a version for each (app, resource type)
    88 and stores these in an array.
    89 
    90 === Remodel the preferences system ===
    91 Details are [wiki:PrefsRemodel here].
    92 
    93 === Dynamic deadline adjustment ===
    94 
    95 Currently, when the scheduler sends a job to the client,
    96 the job has a fixed deadline.
    97 If the job hasn't been completed and reported to the scheduler by then,
    98 the server will generate a new instance the job.
    99 In some cases this is wasteful.
    100 If the client is 90% finished with the job by the deadline,
    101 it may be better to let it finish than to create a new instance.
    102 The proposal, in general terms:
    103  * Have the client report the status (fraction done and elapsed time) of in-progress jobs.
    104  * Allow the scheduler to extend the deadlines of jobs under some conditions.
    105 
    10642
    10743== Small and medium-size projects ==
    … …  
    11955 1. Change the prefs code to use simplexml() for XML parsing; simplify the code in general.
    12056 1. Add a Reset button to prefs (both general and project)
    121  1. 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.
     57 1. Add a timezone setting to the user prefs and convert time to this timezone
     58  (tricky part is daylight savings time) or use a browser setting (if available) when displaying time.
    12259 1. In the forums, provide an interface for moderators to hide a lots of posts at once
    12360  (with checkboxes and a button)
    … …  
    204141   (related to #715)
    205142 1. XML stats: add lat/long to user record?
     143
     144== Major projects ==
     145
     146=== Handle heterogeneous GPUs ===
     147
     148Currently BOINC requires that all GPUs of a given vendor (NVIDIA, ATI, Intel) be similar,
     149and it treats them as a single pool
     150(i.e. jobs are not associated with a particular GPU instance).
     151This model has a number of drawbacks on machines with multiple different GPUs.
     152
     153Change the model so that each GPU is treated separately.
     154This will require extensive changes to the client, scheduler, and RPC protocol.
     155
     156=== Eliminate O(n!^2) algorithms ===
     157
     158The client's job scheduler has several O(N!^2) algorithms,
     159where N is the number of jobs queued on the client.
     160These cause the client to use lots of CPU when N is large (1,000).
     161Change these to Nlog(N).
     162
     163=== Automated testing of BOINC ===
     164
     165Help us add unit tests to the BOINC code,
     166and to design end-to-end tests that exercise the entire system
     167under a range of use cases and error conditions.
     168
     169=== Accelerating batch completion ===
     170
     171Volunteer computing resources are unreliable - computers fail,
     172people uninstall BOINC, and so on.
     173Roughly 5% of jobs fail or time out.
     174This means that in a batch of 10,000 jobs, 500 or so will fail.
     175We retry these (after a delay of a few days) and 25 or so will fail, and so on.
     176Thus is can take quite a long time to finish the entire batch.
     177
     178This problem can be solved by using more reliable computers to handle retries
     179and jobs at the end of a batch.
     180Doing so, however, is tricky.
     181We have some ideas on how to
     182[PortalFeatures prioritize batches] and [JobPrioritization prioritize jobs].
     183Complete these designs and implement them.
     184
     185=== Improve app version selection ===
     186
     187The scheduler's logic for selecting app versions is clumsy.
     188Replace it with logic that, at the start of a request,
     189selects a version for each (app, resource type) and stores these in an array.
     190
     191=== Remodel the preferences system ===
     192Details are [wiki:PrefsRemodel here].
     193
     194=== Dynamic deadline adjustment ===
     195
     196Currently, when the scheduler sends a job to the client, the job has a fixed deadline.
     197If the job hasn't been completed and reported to the scheduler by then,
     198the server will generate a new instance the job.
     199In some cases this is wasteful.
     200If the client is 90% finished with the job by the deadline,
     201it may be better to let it finish than to create a new instance.
     202The proposal, in general terms:
     203 * Have the client report the status (fraction done and elapsed time) of in-progress jobs.
     204 * Allow the scheduler to extend the deadlines of jobs under some conditions.
     205