For the betterment of BOINC
21 Jul 2017 10:25:38 UTC
Topic 208874
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
The piece of BOINC for which
The piece of BOINC for which I think improvement would be most broadly helpful would be in the problems encountered with systems running mixed loads. There are problems in task completion time estimation encountered when a system mixes applications from the same project, when a system has more than one computing resource (CPU vs. GPU, or worse yet, multiple non-identical GPUs), and mixed projects.
While I respect that this is a hard problem, and also that Einstein, sticking on older project-level code, may not give me a view of the current state-of-the BOINC art, I think this general area is one of real opportunity.
The twin goals of improvement should be that casual users get a system that does something reasonable with little or no user guidance, and that expert users have useful opportunities to adjust the default outcomes to their liking by means which behave somewhat the way a reasonable person might hope.
I don't know what the technical characteristics of a more successful system than the current one might be, although one tweak might be some sort of "bleed-in" in which an application, project, or piece of hardware newly introduced to a system only is allocated a small amount of downloading compared to that which a simplistic calculation might lead pending actual experience accumulated on the system at hand. In other words, my reading of users postings here is that unexpected over fetching in marked degree is the most common avoidable user complaint (yes they could avert most of it by setting much shorter queue depths, but they don't).
That tweak, however, would not address the deeper underlying problem at all.
Another common complaint seems to be resource share between projects very different than the user expects over the short and medium term. I don't have any bright simplistic ideas to offer for that one.
I'll second Archae86's first
I'll second Archae86's first point. Mixed workload behavior is terrible and only getting worse as the CPU GPU performance gap opens wider. I've been told Credit New was supposed to fix that; but it proved very controversial at release and whatever Boinc devs may have hoped limited adoption means that it's not capable of solving the problem. Something needs added/backported in the client to address this. A minimum functioning level for that would seem to be maintaining a per app DCF value along with the current project wide one (I suggest keeping this mainly in the hope that for projects that are CPU or GPU only it would allow a saner default than setting each new app to 1).
Ageless wrote:Richard
You don't actually say you accepted the invitation ... :-) but I assume this message means you did. :-).
In which case I'm very pleased that two competent and sensible people were successfully co-opted. ;-).
I think the goal should be to keep BOINC well and truly out of the average volunteer's thoughts :-). Virtually all new recruits should be enticed into supporting a particular project because they are interested in/intrigued by what a particular project is trying to achieve. The PR should be coming from the project itself. Once enticed to join, BOINC should be largely 'invisible' because it just works and doesn't create any negative impacts on the volunteer.
I fully appreciate that the only way to do this is to have a team of skilled people who are competent to do all the extra things you mentioned after the above snip. Unfortunately, this would come from outside the standard volunteer community, in the main. It's probably up to the bigger, well established projects, to provide some of their staff time towards the continuing development of BOINC. I imagine this already happens but there probably needs to be more of it.
BOINC based projects make huge cost savings because of the support of volunteers. They should be willing to spend a fraction of those savings on employing BOINC developers. A relatively small subset of volunteers may have the time and skills to contribute as well. These people would more likely get involved in the first place because they heard of an interesting project rather than just hearing of BOINC.
My answer would be quite skewed. For quite a while now, I've only supported the Einstein project. I have no relevant knowledge about how various projects in different mixes might impact on each other. That may be the most important issue for the average volunteer.
Within this single project, the fact that estimate corrections for one app type always impact on the estimates for other app types is probably a frustrating issue for most people. If having a per app DCF would immediately fix this in a reasonably easy-to-implement fashion, I imagine it would have been done a long time ago. It doesn't bother me at all since I understand how best to cope with it for my purposes.
Another issue is that people often use Einstein as a backup project for Seti. They tend to use a large work cache in an attempt to not run out of Seti work. This can cause problems with over fetching here. I don't know how feasible it would be to implement a new computing option that was able to temporarily reduce a large work cache setting for those situations where a host was attached to both projects and the Seti project was unable to supply.
I sincerely hope not!! :-) BOINC Manager should do just one thing and do it extremely well. It should provide management access to the BOINC client. End of story. It's the old Unix mantra. Have small tools that each do one thing extremely well. The swiss army knife approach always seems to be a recipe for problems.
I'm not a programmer. I don't have the time or skills to become one. The time I have is devoted to maintaining my hosts and contributing to the Einstein project.
Questions 3 and 4 are not applicable to me as I'm not a programmer.
One final comment. I'm very pleased to see you two involved. I wish you every success with your endeavours.
Cheers,
Gary.
Thanks for that. One extra
Thanks for that.
One extra thing I should explain, the development and programming of BOINC is these days done by the community, not solely anymore by David, Rom and Charlie. All three of them work on BOINC on voluntary basis as well. With BOINC I mean all parts of it, be it client, manager, screen saver, back-end, front-end, forums or API. The release of clients to Windows/Mac/Android is still done 'via Berkeley' but actually built by volunteers, while Linux is done by the distro's package maintainers.
I can tell you that the work group we're in is comprised of not the least people in BOINC. I'm still flabbergasted they asked me and that they listen to what I have to say. And while their attention is mostly set to how we can get more people to program for BOINC and why past volunteer developers left, I'm sure Richard and I can bring forward the most interesting ideas.
Richard and I are the community representatives of the work group. Funny thing is, they wanted us to choose between ourselves as they only needed one person. We couldn't decide between ourselves who was better, so I asked if we couldn't both join, also so we had backup in case either of us couldn't make a meeting one day. After getting the OK on that, Richard immediately went on a week's holiday, leaving me to do all the prep work the past week.
Last, David is busy with a next plan, temporarily called TBD, which simply said is a forefront to BOINC through which users can choose what kind of work they want to run, and the correct project(s) will be added and work for that project will then be sent. So you don't choose a project anymore, but you choose that you want to run Space->Search for Black Holes.
Keep everything coming. We'll be collecting everything everyone gives out in the various forums.
Now, let's see if I can post this with RAC 0.
So you don't choose a project
I'm sorry, but I must immediately disagree with that approach. I would suggest that a very large proportion of people support a Boinc Project because of a myriad of reasons. Some scientific, some personal and yes, some out of simple loyalty over many years.
You guys have to realise that BOINC is just an umbrella Project that sought to prove the viability of distributed computing using the general public. It proved its point, the original experiment is over. It is now down to the individual projects running under the BOINC umbrella to attract people in their own way given the nature of the individual projects aim.
What you guys should be doing is to encourage the world at large to get involved in Distributed Computing as a principle, and let people choose their own project for their own reasons, and not just assume blithely that it will be because of what the project is running.
And if you want to do something really useful, how about getting all projects to give the same level of credits, rather than the discrepancy that we have now. Many people choose projects for credits not the values of the work done. That goes against the whole original idea of BOINC.
Waiting for Godot & salvation :-)
Why do doctors have to practice?
You'd think they'd have got it right by now
Ageless wrote:After getting
It was a lot less than a week, but felt like more - I'm shattered, but back home now and recovering. I have a whole heap of emails and message board posts to catch up on, even after trying to keep up with the email conversations on dodgy B&B WiFi. But yes, I'm in, and hopefully up to speed again by early next week.
Chris S_2 wrote: So you
Unfortunately, we don't (yet) have control over what the NSF will fund. We might just have an influence over how the next funding application is written, and who it is submitted to.
Hi Richard, Unfortunately,
Hi Richard,
That would be really great if it happened, and I'll back you all the way in that. I am just dubious about cosmetic tinkering with the Boinc front end.
Waiting for Godot & salvation :-)
Why do doctors have to practice?
You'd think they'd have got it right by now
... So you don't choose a
... So you don't choose a project anymore, but you choose that you want to run Space->Search for Black Holes.
... For example to add social media inside BOINC Manager
These ideas sound like a nightmare... If possible, please focus your effort on technical issues with scheduling or bugfixes and do not waste your limited time with unproductive toys...
Well, somebody's got to
Well, somebody's got to persuade the developers not to waste their time with unproductive toys...
... or to add the toys that people a lot younger than me are already used to these days. We need to hear both sides of the argument.