Hi BOINC Community,

Last week Richard Haselgrove and I were asked to join a BOINC Work Group committee which researches how BOINC can be made more user friendly, easier for anyone to set up their own short- or long term project, and for the community to join in on those endeavours. The goal is to get more people to run BOINC, to join in coding all parts that make BOINC (client, manager, web site, forums, projects, etc.), to test everything, to get them to set up their own projects, to make BOINC a future-proof and reliable brand that isn't dependent on any one person in particular.

We do know this is a big order and it won't be solved in a couple of weeks. So we'll work in the background together with some key people from projects/code developers to get things started. Eventually we will need answers from you as well, probably on a lot of things. But we'll start slow with a couple of small questions:

1. If there is anything at all you can change in/withdraw from/add to BOINC, what would that be? While we don't exactly look for enhancements or bug squashing, you may just let out anything you think would put BOINC on the map. For example to add social media inside BOINC Manager, or have certain add-ons integrated into the client (I am making these up, they aren't on the list (yet)).

2. Would you like to contribute to making BOINC better, or program for it, or walk the source code, or do anything to help the project forward? What has held you back thus far?

3. We'd like to get into contact with people who programmed for BOINC, but no longer do. Can you PM me or Richard on this, or contact me via email? Especially if you're one of the people in the Volunteer Developers section here.

4. We also like to get into contact with people who now voluntarily program for BOINC. Can you tell us why you decided to work on BOINC, how difficult it was to get into and what we can do to increase your involvement?

With thanks for any answers you have,

Richard Haselgrove
Jord van der Elst

1. Adding social media is a good idea (just make it subtle, I've become allergic to "share this on fb!").
Make credits more public, so that whenever I share on fb or instagram, people can see how cool I am due to my credits.
More user friendly UI... More "Mac-ish" (for a lack of a better term), simple buttons, rounded corners, big progress bar (I'm thinking in place for the current "simple view")... Something like: "You are now modelling protein X, involved in Alzheimer's disease, click here to learn more -> link to more in-depth science article regarding the research"
Non-tech people like simple non-intimidating UIs. This is specially true for mobile apps.

2. Yes. Lack of a straightway to get involved (my fault probably, I haven't researched enough, but a button in the boinc manager or a link in the project's website that says "are you a developer and want to help BOINC? Click here!" would help).
I could help with the Android App.
I have very little experience developing windows programs (I have more experience with higher level languages for specific purposes, like MATLAB, etc...) but it could easily become a hobby for me given enough time to get over the learning curve.

3. N/A

4. N/A

---

2. Yes. Lack of a straightway to get involved (my fault probably, I haven't researched enough, but a button in the boinc manager or a link in the project's website that says "are you a developer and want to help BOINC? Click here!" would help).

So simple. I like it. I'm taking that one along to tonight's meeting.

I could help with the Android App.
I have very little experience developing windows programs (I have more experience with higher level languages for specific purposes, like MATLAB, etc...) but it could easily become a hobby for me given enough time to get over the learning curve.

All the help is welcome.
I'd say, start at https://github.com/BOINC/boinc/issues, look around. If you don't feel too overwhelmed yet, take a peek at https://boinc.berkeley.edu/trac/wiki/SourceCodeGit for what's needed to get the source code. I would urge you to contact the volunteer developer for Android, Oliver Bock (@brevilo). You can chime in via #1846

Hi all,

First I'd like to thank those of you who took the time to post your grievances, feature requests and suggestions. We have quite a list already, but we'd love more. I can tell you that all of what makes it through to the list will be spoken about in detail between the group members and possibly back to you who asked about it.

Just so you know, this work group isn't some low people who were aimlessly waiting around in the lobby of some university, instead as I hinted in some posts already, these people aren't the least in BOINC, they do have something to say. They are senior project scientists and administrators, and other significant contributors.

Meet:
- Christian Beer - Einstein@Home
- David Wallom - Climateprediction.net
- Eric Korpela - Seti@Home
- Kevin Reed - IBM/World Community Grid
- Laurence Field - CERN/LHC
- Tristan Olive - Grid Republic
- David Anderson - BOINC

So yes, we're quite honored in that they asked us to gather around the table to discuss a lot of things about BOINC, and so should you. All the material Richard and I send in is talked about via email/a dedicated website. There's so much to talk about even, that some of it made it impossible for us to do all the Agenda points on the last weekly meetings. :)

Weekly we talk via teleconference with each other, which is really nice as at least that way the others can hear the urgency in my voice on anything I have to say. And that's not all just serious talk, there's a lot of humor passing by as well. Weirdly enough, sometimes these guys sound and act like humans. :-D

With that out of the way, please, continue. Give us a lot more to talk about, to decide upon, to vote on how we should change things. We're proud of you. We're BOINC, resistance is futile. :)

Jord.
Richard.

I might be a bit late here, but I'd like to see Efmer's Tthrottle incorporated (all parties willing!). Basically I'd like to BOINC being able to thermally throttle the projects, especially on a laptop.

I'd also like to see better cross-platform parity. I know there are difficulties in like-for-like comparisons, but basically I guess the thing it comes down to is how much are we saving the researchers if they were having to pay for similar time on a service like a supercomputer or AWS.

This one is not a priority, and more of a question: I'm not sure how the more modern processors deal with BOINC with regards to the various auto-overclocking features such as XFR on Ryzen, but there might be some work to optimise those(?)

---

It has been asked several time in the BOINC forums, but controlling core use during "In use" and "Idle" automatically could be of great benefit.
It's a big hassle to snooze BOINC or limiting the core count use and then letting BOINC "use all it wants" once I'm done working.

This would help the "I like to help but I don't like BOINC getting in my way while I'm working" people. Heck, even I forget to unsuspend BOINC once I'm done working (and I'm dedicated).

For example, take a 4 core CPU. If you let BOINC run on all 4 cores, you're gonna see a performance hit no matter the priority of the WU (specially with rosetta). But if you automatically limit the core use to just 1, then you won't see any performance hit . Then, once the PC is "idle", increase the core use to 4.
In my opinion, this is a better approach to the issue than the "suspend BOINC work when non-BOINC work takes above 25% of total CPU time". Simpler too (all you have to do is modify the core % in preferences (?) )

---

Already in Github Issues:
Throttling: #1474 and it may make it into BOINC 7.8, seeing the latest tag.
Temperature measuring for GPU: #1378 and #1379
Different CPU use when in use/idle: #41

Whatever is in Issues needs to be done at some point, but we're deliberating on how to do so. Our amount of programmers is finite, it's really only a handful.
Therefore our call for help.

Yes, I'd like a button for graphics to show for all the cores, 15 FPS seem a good rate, but I want to immediately, see what each core is doing, not to bring each core to show its 3D protein graphics.

I'd like to suggest since unfortunately can't code, to go for a code optimization for efficiency and speed, sometimes compilers don't make the best code, and we need all the optimizations CPU have, and why not, CPU/GPU designers do it for that reason, better instructions

Getting rid of CreditScrew would be a good start!

I agree with rcthardcore regarding CreditScrew.
Here it seams that an Intel(R) Celeron(R) CPU G1620 @ 2.70GHz [Family 6 Model 58 Stepping 9]
(2 processorer) ar producing more than twice the credit as I get running an 15 core (32 thread) @4GHz AMD Threadripper on full load or should I take it that
a Threadripper is a bad choice regarding efficiency if you want ro run Rosetta?

Here it seams that an Intel(R) Celeron(R) CPU G1620 @ 2.70GHz [Family 6 Model 58 Stepping 9]
(2 processorer) ar producing more than twice the credit as I get running an 15 core (32 thread) @4GHz AMD Threadripper on full load or should I take it that
a Threadripper is a bad choice regarding efficiency if you want ro run Rosetta?

That is my problem, as I use credits to check my equipment. I never know whether what I am seeing is real, or a figment of the imagination.

---

Here it seams that an Intel(R) Celeron(R) CPU G1620 @ 2.70GHz [Family 6 Model 58 Stepping 9]
(2 processorer) ar producing more than twice the credit as I get running an 15 core (32 thread) @4GHz AMD Threadripper on full load or should I take it that
a Threadripper is a bad choice regarding efficiency if you want ro run Rosetta?

That is my problem, as I use credits to check my equipment. I never know whether what I am seeing is real, or a figment of the imagination.

I will try out running cpu work units under Folding@home and try to find other medical projects under BOINC that has a better credit system than this.
It is hard to understand that it can be so complicated to make a fair credit system that is based on the work you are produce and nothing else.

For myself, I don't really compare credits with someone else. But I do need consistency for my own work, to compare operating systems, CPU types, or GPUs when that is the case.
I think the main objective of credit new was to prevent cheating, but making it worthless for all purposes is not the way to go.

---

I need a working credit system to evaluate which CPU, GPU, OS to use with which project to make it as effective as possible.
I remember that when I was running SIMAP I could see, based on credit I got, that my AMD FX8350 was more effective than Intel 3770K so based on that I used my FX8350 to run work units under SIMAP.

In projects like SETI where the wingman can be either a CPU or GPU, your own credit can vary. It's not really credit for work done any more when the same work is 100 points for one wingman and 50 for a different type of processor on another wingman get the same work was done. I still prefer a fixed credit for a given task size/length. Let the completion time and # of tasks per day determine which processor get more credit overall, Much easier to compare performance as well.

I need a working credit system to evaluate which CPU, GPU, OS to use with which project to make it as effective as possible.
I remember that when I was running SIMAP I could see, based on credit I got, that my AMD FX8350 was more effective than Intel 3770K so based on that I used my FX8350 to run work units under SIMAP.

I think everyone would like that. 8-) Even those running the projects. It is very difficult to do.


On Win10 I use the Windows TASK MANAGER to monitor especially the DISK and NET usage. I check out any activity on either one of those.
I use BoincTasks to monitor BOINC WU. I watch the CPU usage of GPU task and MEMORY use of WU.
Einstein GPU tasks take 99% of a CPU and about 1GB of virtual memory on my machine. MilkyWay uses 0% CPU.
Rosetta WU MEMORY usage seems to bloat up to 1GB+ just before CHECKPOINTING.

I use GPU-Z to monitor the loads on the GPU and memory traffic.

I back off the CPU available to CPU jobs until I see the TASK MANAGER CPU drop below 100% and then add a CPU back in. For my 12-core i9-7920X, I had to exclude 2 threads from BOINC CPU WU.

The PROJECTS tend to optimize for a single thread which likely negatively affects the total throughput.
PrimeGrid aggressively prefetches all the data into the CPU caches before starting to crunch.
If you run 1 PrimeGrid WU per CORE, you get shortest compute time.
If you run 1 PrimeGrid WU per THREAD, there is an 80% slow down. You do more work if you use all the THREADS. Just slower.

Many projects break off a fixed length problem and allocate to the volunteer.

Rosetta gives a computer a LONG WU problem and a TIME PERIOD to work on it. If you set your computer TIME to 24 hours, you will see many WU finish much sooner than 24 hours. When I was looking at Rosetta performance, I used a shorter fixed problem where the run time was repeatable and comparable.

Rosetta has a big code footprint. They compile with high optimizations and aggressive INLINE options.
Rosetta does very little floating point. When it does, it does 3D coordinate floating point LOAD, ADD/SUB/MUL, STORE .... 3 times in a row.

When I looked at the new 4.0 version, It spends a significant amount of time spinning on LOCKS. 4.0 seems to do even less floating point.

I need a working credit system to evaluate which CPU, GPU, OS to use with which project to make it as effective as possible.
I remember that when I was running SIMAP I could see, based on credit I got, that my AMD FX8350 was more effective than Intel 3770K so based on that I used my FX8350 to run work units under SIMAP.

I think everyone would like that. 8-) Even those running the projects. It is very difficult to do.


On Win10 I use the Windows TASK MANAGER to monitor especially the DISK and NET usage. I check out any activity on either one of those.
I use BoincTasks to monitor BOINC WU. I watch the CPU usage of GPU task and MEMORY use of WU.
Einstein GPU tasks take 99% of a CPU and about 1GB of virtual memory on my machine. MilkyWay uses 0% CPU.
Rosetta WU MEMORY usage seems to bloat up to 1GB+ just before CHECKPOINTING.

I use GPU-Z to monitor the loads on the GPU and memory traffic.

I back off the CPU available to CPU jobs until I see the TASK MANAGER CPU drop below 100% and then add a CPU back in. For my 12-core i9-7920X, I had to exclude 2 threads from BOINC CPU WU.

The PROJECTS tend to optimize for a single thread which likely negatively affects the total throughput.
PrimeGrid aggressively prefetches all the data into the CPU caches before starting to crunch.
If you run 1 PrimeGrid WU per CORE, you get shortest compute time.
If you run 1 PrimeGrid WU per THREAD, there is an 80% slow down. You do more work if you use all the THREADS. Just slower.

Many projects break off a fixed length problem and allocate to the volunteer.

Rosetta gives a computer a LONG WU problem and a TIME PERIOD to work on it. If you set your computer TIME to 24 hours, you will see many WU finish much sooner than 24 hours. When I was looking at Rosetta performance, I used a shorter fixed problem where the run time was repeatable and comparable.

Rosetta has a big code footprint. They compile with high optimizations and aggressive INLINE options.
Rosetta does very little floating point. When it does, it does 3D coordinate floating point LOAD, ADD/SUB/MUL, STORE .... 3 times in a row.

When I looked at the new 4.0 version, It spends a significant amount of time spinning on LOCKS. 4.0 seems to do even less floating point.

I have run Folding@home, the GPU application, for years and that seams so work very well regarding credit and how different cards performs on average over time.
Now I will start running CPU applications as well to see how that works comparing with this and other projects under BOINC.

A major difference with Folding@home as I understand is that their software is made by professional programmers while the various programs in projects under BOINC
sometimes are made by programmers that ar far less experience in programming.
I remember the difference Cluster Physics made when he rewrote the program running in Milkyway@home and made it run 10000 times faster than the original program.

null

FAH is benchmarked on one system and assigned a fixed base credit based on how it performs on that CPU and GPU. That system has changed over the years but it allows for much closer average PPD across it's types of work units. QRB has widened that range of PPD for faster GPUs due to its non-linear formula.

CreditNew seems to try use the Whetstone benchmark to get that even RAC/PPD across many systems vs benchmarking it on one system like FAH. Benchmarking on one system with many projects isn't very feasible.

Since many of you seem interested, and mystified by the credit system at R@h, I'll try to clarify a few points. Some other projects simply use CPU seconds, or FLOPS of a task to issue credit. The problem with such a system is that it doesn't reward machines that achieve more work per second due to CPU cache, and memory available. It also depends upon the BOINC Manager to track and report the FLOPS expended on a task, and so some users began to falsify the FLOPS benchmarks and thus the FLOPS of their reported results.

To avoid these problems and design a credit system that would work going forward through new generations of hardware and capabilities, a system was adopted whereby credit granted is based on what OTHER user's machines have claimed for how difficult it is to complete each decoy (or model) of a task. The average of the results reported before you is used, rather than an arbitrary benchmark. So the credit granted does not favor a specific CPU type or operating system. It truly is based on completed work. Some tasks use different algorithms to compute their results. Assessing the effectiveness of a variety of algorithms is how the science progresses. This results in variations on computing resources required to complete them. Each type of task self-adjusts the credit it awards.

This makes a credit system that is great at reflecting the value of work to the Project Team, but makes it more difficult to benchmark your own machines. To do that well, you would have to run the same task, from the same starting seed for each benchmark run, and then compare CPU and wall-clock time, as well as the number of decoys produced. The BOINC Manager doesn't have a means of easily supporting this type of usage. Running tasks for other projects or a different class of proteins only tells you about those things. One machine might be faster than another at one type of work, and not with another type. The R@h credit system reflects the value of the outcome, without bias.

---

Rosetta Moderator: Mod.Sense