| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: NSF funds new model for BOINC |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 12
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Read again here: http://boinc.berkeley.edu/tbd.php TBD is just for new demographics & easier to use BOINC. To quote: "I suspect that relatively few current volunteers will use TBD; it's more for new users with wider demographics. So current projects won't lose computing power, and they should get additional power from TBD. Long term, I think something like TBD is our only hope for going from a few 100K volunteers to millions or tens of millions. And such a rising tide will float all of our ships." Main difference is about making BOINC portable to HTC/HPC & making sure some labs run their facilities at 100% of time, when work is not allocated.  Will it also be on some paying cluster? That I do not know. I would respectfully suggest you follow your own advice and pay particular attention to the details. Re-read several times if you must. Dr. Anderson: "We will complete and extend current work adding BOINC-based VC back ends to existing computing providers: nanoHUB and the Texas Advanced Computing Center (TACC. Qualifying HTC jobs will be automatically migrated to VC and run on consumer devices. This will benefit thousands of scientists using nanoHUB and TACC by increasing HTC capacity and freeing HPC resources for other jobs. Scientists wonât have to learn or change anything â theyâll just get faster turnaround. These key integrations will provide software building blocks by which other computing providers (HPC centers and science gateways) can add VC back ends." It would be completely unreasonable to expect an existing multi-million dollar facility to "convert" to running BOINC on their cluster. However, it would be totally reasonable to "enhance" their current environment with a BOINC back-end that adds additional compute resources at minimal expense. It is also noted that not ALL work on the clusters will be run through BOINC as indicated by the words "qualifying HTC jobs...". Therefore, they must maintain their existing structure for jobs that don't qualify. From the proposal: " Having the ability to use VC to provide the necessary cycles will enable TACC to allocate more time on HPC systems to projects whose science requires tightly-coupled parallel computing." And finally: "3.1 BOINC adapters We will complete and extend current work aimed at allowing HTC systems to offload suitable workloads – large batches of independent jobs with moderate storage and memory requirements, and no data privacy requirement – to BOINC-based back ends. We are doing this in a way that is transparent to the users of the HTC systems, and that requires as few changes as possible to the systems. Our approach involves 7 “BOINC adapters” that interface between the HTC systems and BOINC. These adapters perform several functions: Package application executables using the VM/Docker approach described in Section 1.3. Translate HTC jobs into BOINC jobs. Stage input files – make them available via HTTP to volunteer devices. Allow the HTC system to query the status of jobs, to control (e.g. abort) existing jobs, and obtain the output files and/or error information from completed jobs. Map the HTC identity of the job submitter to a corresponding BOINC identity, so that BOINC’s access control and quota mechanisms can operate. BOINC provides Web remote procedure calls (RPCs) that facilitate the development of adapters, and we have experience developing efficient adapters. For example, we developed an adapter for HTCondor that can create and monitor thousands of jobs per second." |
||
|
|
KLiK
Master Cruncher Croatia Joined: Nov 13, 2006 Post Count: 3108 Status: Offline Project Badges: 
|
Read again here: http://boinc.berkeley.edu/tbd.php TBD is just for new demographics & easier to use BOINC. To quote: "I suspect that relatively few current volunteers will use TBD; it's more for new users with wider demographics. So current projects won't lose computing power, and they should get additional power from TBD. Long term, I think something like TBD is our only hope for going from a few 100K volunteers to millions or tens of millions. And such a rising tide will float all of our ships." Main difference is about making BOINC portable to HTC/HPC & making sure some labs run their facilities at 100% of time, when work is not allocated. Will it also be on some paying cluster? That I do not know. I would respectfully suggest you follow your own advice and pay particular attention to the details. Re-read several times if you must. Dr. Anderson: "We will complete and extend current work adding BOINC-based VC back ends to existing computing providers: nanoHUB and the Texas Advanced Computing Center (TACC. Qualifying HTC jobs will be automatically migrated to VC and run on consumer devices. This will benefit thousands of scientists using nanoHUB and TACC by increasing HTC capacity and freeing HPC resources for other jobs. Scientists wonâÂÂt have to learn or change anything â theyâÂÂll just get faster turnaround. These key integrations will provide software building blocks by which other computing providers (HPC centers and science gateways) can add VC back ends." It would be completely unreasonable to expect an existing multi-million dollar facility to "convert" to running BOINC on their cluster. However, it would be totally reasonable to "enhance" their current environment with a BOINC back-end that adds additional compute resources at minimal expense. It is also noted that not ALL work on the clusters will be run through BOINC as indicated by the words "qualifying HTC jobs...". Therefore, they must maintain their existing structure for jobs that don't qualify. From the proposal: " Having the ability to use VC to provide the necessary cycles will enable TACC to allocate more time on HPC systems to projects whose science requires tightly-coupled parallel computing." And finally: "3.1 BOINC adapters We will complete and extend current work aimed at allowing HTC systems to offload suitable workloads â large batches of independent jobs with moderate storage and memory requirements, and no data privacy requirement â to BOINC-based back ends. We are doing this in a way that is transparent to the users of the HTC systems, and that requires as few changes as possible to the systems. Our approach involves 7 âBOINC adaptersâ that interface between the HTC systems and BOINC. These adapters perform several functions: ï· Package application executables using the VM/Docker approach described in Section 1.3. ï· Translate HTC jobs into BOINC jobs. ï· Stage input files â make them available via HTTP to volunteer devices. ï· Allow the HTC system to query the status of jobs, to control (e.g. abort) existing jobs, and obtain the output files and/or error information from completed jobs. ï· Map the HTC identity of the job submitter to a corresponding BOINC identity, so that BOINCâs access control and quota mechanisms can operate. BOINC provides Web remote procedure calls (RPCs) that facilitate the development of adapters, and we have experience developing efficient adapters. For example, we developed an adapter for HTCondor that can create and monitor thousands of jobs per second." You said it right...but it's you who need to read it again: Relationship to BOINC In 2016 BOINC became a community-run project; I don't control it. The new project, TBD, will be separate from BOINC. I hope that the BOINC community likes and supports TBD, but some people might not, and I don't want to step on their toes. Of course, I'm interested in hearing comments and criticisms about TBD, and in discussing it. I've been mostly MIA from BOINC for the last couple of years, because I've been working full-time on other projects. I apologize for this. With this new funding, I'll be able to devote a good chunk of my time to managing and contributing to BOINC, e.g. setting up a functional release management process. I suspect that relatively few current volunteers will use TBD; it's more for new users with wider demographics. So current projects won't lose computing power, and they should get additional power from TBD. Long term, I think something like TBD is our only hope for going from a few 100K volunteers to millions or tens of millions. And such a rising tide will float all of our ships. To implement TBD, I'll need to add some features to BOINC, e.g.: The client will pass credit estimate information to account managers. Account managers can send clients opaque data to be passed in scheduler requests (preference keywords in this case). The scheduler will have a "keyword matching" option that takes user and job keywords into account. E.g. it will preferentially send biomed jobs to volunteers who want to support biomed. These features will have no impact on existing projects. The BOINC web site will link to TBD as well as BAM! and GridRepublic. The TBD source code will be released under LGPLv3, and will be stored on Github. We'll welcome code contributions. I've also put the bolds for you, to be easier. |
||
|
|
|