Well, one of the reasons I have been crunching for many years now is that I also became member of an active team, which can be much more motivating than crunching alone all the time. I suspect this is true for many others, as well, but if we all started quoting our team descriptions here as part of the reason we are crunching, it would be just like the team recruitment forum.

As the funding is already granted, we should rather try to give constructive feedback to David's ideas:

Partner with existing HTC computing providers such as supercomputing centers and science portals to add BOINC-based back ends. These projects would be operated by the provider's staff. Tens of thousands of scientists use such computing providers. These scientists would benefit from lower queueing delays, higher throughput and lower cost. But they wouldn't need to do anything; they wouldn't even need to know that VC is being used.

If the HTC providers don't offer the BOINC-based service for free, they are basically selling the resources donated by the volunteers. They will have to be very transparent on that, as there will certainly be volunteers who don't like that their donations are sold and are angry if they learn about that too late. IMHO, also the 'TBD' account manager should have an opt-in checkbox to allow this kind of projects only if it's really the user's choice. If the HTC providers were paying the volunteers for their 'donation' (I remember that long time ago there was a project that wanted to do exactly that, but it never really came to life), this would open another can of worms and likely also lead to decreased enthusiasm in the long term.

In addition, I don't think that the vbox mechanism, which would be used heavily by those projects, is working well enough yet. For example, the tasks are running with normal priority instead of idle priority and you won't be able to use your computer, if you are running more than one task per physical core on a very common i7 CPU with hyperthreading (with default settings, BOINC would run one task per thread, i.e. two tasks per physical core). This is far away from the basic idea that BOINC is using the spare cycles while the users may continue using their computers as usual. It is also not trivial to set everything up correctly, even long-time enthusiasts sometimes have trouble to get a vbox project to run. If newcomers get attached to such problematic projects first, they might just uninstall BOINC and never come back.

If the problems with vbox are going to be fixed now, it'll be great also for the traditional projects and the current volunteers. But if just more and more vbox projects were created, that would be taking the second step before the first.

Create an account manager (let's called it "TBD" for now) acting as the primary volunteer interface. TBD lets volunteers express their preferences in terms of keywords (scientific areas and locations) rather than selecting specific projects. Based on these preferences, and corresponding keywords of projects and applications, TBD dynamically assigns computers to a set of vetted projects, which would include both existing (single-group) projects, as well as the new computing-center projects.

I agree that likely very few current volunteers will be interested in such a platform, but it could in fact make things a bit easier for newcomers.

I also see a few ways to improve BOINC in order to make "TBD" a success which would also be appreciated by many current volunteers. For example, I can imagine that there might be "TBD" users who want to give two cores of their quadcore CPU to biomed and the other two cores to astrophysics. Over the years, I frequently read newcomers asking why they can't (easily) set that x cores should be used for project A and y cores for project B. Of course, there is already the resource share mechanism, but it works only in the long run and newcomers tend to be a bit impatient. Credits are another point; a fair system that depends on the actual project-specific work done would be easier to explain to newcomers than some kind of lottery trying to square the circle.

Overall, however, I would be surprised if there were millions of new volunteers just waiting for new platforms like the new account manager. The main problems are that 'new' devices like smartphones or tablets can be used for VC, but are not particularly well-suited for it (battery life, cooling) and that the power-saving mechanisms have advanced quite a lot in the last ten years, so we lost the important selling point that while the volunteer is using the computer as usual, it could do something useful with all the spare cycles in parallel without significantly increasing the power consumption. Unfortunately, there's no plausible way that the environment improves again in favor of VC, so all we can do is to keep the fire of enthusiasm alive.

---

I concur.

Doesn't using a BOINC account manager eliminate the need to setup accounts on each project?
I have not used one. So I could be certainly be mistaken.
I was under the impression a user would create an account, log into the account manager, and then select projects to run.


I think to really catch on with mobile devices it would need to "play to the audience".
An app with a simple interface would be needed. Along the lines of scanning a QR code and then let them sign in with their social media account.
Then to provide the user some incentive to let the software run. Why will people buy a $3 pink wrist band to help fund breast cancer research, but not let an app run on their phone while it charges overnight?

Having the infrastructure and an organization where groups/projects could go to have their data analyzed would probably let more types of research get done.
I have seen BOINC projects setup that try to do that, but most of them are not that great at it from the user end.

Doesn't using a BOINC account manager eliminate the need to setup accounts on each project?
I have not used one. So I could be certainly be mistaken.
I was under the impression a user would create an account, log into the account manager, and then select projects to run.

It eliminates them from manually creating each account in the traditional way. It does NOT eliminate having to create an account at each project. It just simplifies the creation process for you. So a rogue project still gathers the logins in theory and can actually see them if set up to do so. No protection to the volunteer at all. It also does not create your profiles for you.

BOINC has many security flaws that shouldn't be taken lightly.

---

Disclaimer: I am a holder of GRC (only $5 worth), but I have no real preference over GRC or other blockchain currencies.

I'd like to add that Gridcoin is currently trading at $0.12 USD/ 1 GRC right now. There are also several other currencies based on decentralized processing of real work that are up and coming.

It seems not officially supporting a work to currency program is a huge missed income opportunity. I believe if Boinc doesn't officially adopt a blockchain (GRC or otherwise), you will very quickly be out of processing power altogether as miners move to other charity/real work to currency programs such as Curecoin. I believe also that projects will begin move to other organizations that are driving an economy of miners. New and old projects alike will follow the processing power.

Quite simply, there is far too much money to be made here, it can't be ignored. Some GRC holders currently own Millions of USD worth of GRC, although it is not completely liquid, it has no where to go but up.

I don't trust the legality or ethics of any cryptocurrency. They are too suitable for tax evasion, money laundering, and who knows what else. I end my crunching days when they become necessary.

I don't trust the legality or ethics of any cryptocurrency. They are too suitable for tax evasion, money laundering, and who knows what else. I end my crunching days when they become necessary.

There is nothing legally or ethically wrong about crypto-currencies. They do not have to be anonymous, wallets could be tied to your SSN# if you like, which would make them more secure then traditional banking networks. American Dollar bills are used for more illegal transactions, money laundering and tax evasion then blockchains are. Many governments around the world are adopting them not only as they are, but building block chains into their existing banking networks.

This is like driving a horse+carriage and saying you don't trust cars. They are the future whether you are interested in them or not, the technology is simply superior for a variety of reasons.

If you have problems with the technology I would be happy to discuss its possibilities and your concerns.

I am not worried about my own account, so tying it to my SSN does not address the issue. It is a question of whether governments can monitor it effectively. Your assurances are not enough. When the U.S. Treasury adopts a given cryptocurrency, then I will consider it.

Two straws in the wind from GPUGrid today:

New publication: Complete protein–protein association kinetics!

Scientists reveal first details at the atomic interactions between proteins

An international team of researchers has simulated the association and dissociation of proteins in atomic detail in just one year. If they had used a supercomputer, this process would have taken 10,000 years to carry out. The results were published in the journal Nature Chemistry .

(Google Translate version of original article in Spanish)

GPUGRID active users are falling dramatically!

Fixing bugs with BOINC is relatively pointless from our perspective (and time-intensive). We are considering rather other options like moving out of it, but don't ask when or how as it's more an idea than a scheduled plan.

I am sorry for those inconveniences that this causes.

The reason we cannot address technical issues with BOINC is that we don't have anyone in the lab anymore who knows his way around it and that priorities are higher on getting scientific work done. Of course you have a point that this will eventually bite us in the ass since we won't be able to do scientific work without crunchers but it's a tricky thing to manage.

It's interesting that the original article I linked makes no mention of BOINC: it credits GPUGrid and NVidia, but not the glue that binds them together. I think that's inevitable - infrastructure should be boring, invisible, and reliable. The second quote should remind us of the ongoing need for maintenance of the existing BOINC framework, which has been sadly neglected for the last two years. GPUGrid has hugely intensive computational needs - their tasks are regularly taking longer than 24 hours on my GTX 970 cards, and that's longer than they would wish. Hardware, drivers, and operating systems are all evolving, and BOINC has to keep up or become irrelevant. I don't see how GPUGrid could be supported under TBD.

I am not worried about my own account, so tying it to my SSN does not address the issue. It is a question of whether governments can monitor it effectively. Your assurances are not enough. When the U.S. Treasury adopts a given cryptocurrency, then I will consider it.

You do realize that governments have no capability of monitoring traditional banking networks right? Crypto-Currencies are in-fact more transparent then traditional networks because the government can open its own node on the block chain and monitor all transactions. Something it cannot do with current networks unless it has a warrant. In the same way bank account numbers do not point to an individual unless you have access to the certified authority who created the account, you can have a certifying authority to connect crypto-wallets to identification of the owners of said wallet.

In short: A wallet address is no different then a bank account number. In the case of a decentralized block chain the government has more power to monitor transactions. Traditional banking networks are more anonymous and opaque then crypto-currencies are, despite what the prefix 'crypto' would imply.

You seem to think the U.S Treasury has any power to monitor private banking networks, which is absurd and completely false. At best they could identify the branch which opened the account, but this is assuming they had access to the transaction in the first place, which they do not.

Ive read your proposal and I'm not comfortable with the direction of this for various reason. As a long time cruncher under various accounts over the years I hope that boinc will continue to be maintained separate from this account manager and the account manager would just be an alternative option for a user. I enjoy selecting what projects, applications and what amount of resources I choose to crunch towards a project as well as various boinc settings I can change to make my system more efficient. It saddens me there is a direction to mainly commercialize boinc with this as well. There is security concerns as well with regards to the account manager being able to allocate resources to projects that is defiantly something that could become exploitable. This account manager should be something thats released as a option along side boinc but separate. This also has the feel that if the boinc community is only partially forced into this account manager then It will be only a matter of time until you push and push more till its the account manager you have no choice but to use. We've seen this countless times in other sectors. I will continue to maintain control in anyway possible to crunch 15% for this project on this application and 50% on that project on these applications,etc as well as settings that optimize my crunching of data.

I will continue to volunteer compute as I see fit with no future influence of such an account manager nor am I going to use an account manager within an account manager either. There are other avenues for a concept like this. it can just be like bam an account manager a user has a choice to attach. I don't believe it should come with boinc software at all unless a user opts to download the addition of it with the software.

Thank you,

It's interesting that the original article I linked makes no mention of BOINC: it credits GPUGrid and NVidia, but not the glue that binds them together. I think that's inevitable - infrastructure should be boring, invisible, and reliable. The second quote should remind us of the ongoing need for maintenance of the existing BOINC framework, which has been sadly neglected for the last two years. GPUGrid has hugely intensive computational needs - their tasks are regularly taking longer than 24 hours on my GTX 970 cards, and that's longer than they would wish. Hardware, drivers, and operating systems are all evolving, and BOINC has to keep up or become irrelevant. I don't see how GPUGrid could be supported under TBD.

Wrong example.
In Italy we say "scaricabarile" (something like "pass the buck").
Gpugrid SW is buggy, slow, not optimize also without "ipotetical problems" on Boinc infrastructure.
They don't support cpus or amd gpus or android, they support ONLY Nvidia Gpus and, despite this, EVERY new release of driver they have problems.

It's interesting that the original article I linked makes no mention of BOINC: it credits GPUGrid and NVidia, but not the glue that binds them together. I think that's inevitable - infrastructure should be boring, invisible, and reliable. The second quote should remind us of the ongoing need for maintenance of the existing BOINC framework, which has been sadly neglected for the last two years. GPUGrid has hugely intensive computational needs - their tasks are regularly taking longer than 24 hours on my GTX 970 cards, and that's longer than they would wish. Hardware, drivers, and operating systems are all evolving, and BOINC has to keep up or become irrelevant. I don't see how GPUGrid could be supported under TBD.

Wrong example.
In Italy we say "scaricabarile" (something like "pass the buck").
Gpugrid SW is buggy, slow, not optimize also without "ipotetical problems" on Boinc infrastructure.
They don't support cpus or amd gpus or android, they support ONLY Nvidia Gpus and, despite this, EVERY new release of driver they have problems.

Maybe, but imagine how much easier their life would be if BOINC was helping, rather than hindering?

Maybe, but imagine how much easier their life would be if BOINC was helping, rather than hindering?

Boinc have to be "agnostic" regarding software that runs.
The help that boinc admins have to do is to fix bugs and update documentation (and, maybe, introduce new functionalities).
In which way they "hinder" the project?

P.S.
If gpugrid admins are not happy of boinc, they can always buy computational resources on Amazon, Azure, etc and it's NOT free (as they are used to).

BOINC does not "own" any hardware resources. At the server end of the chain it is a software environment which runs server hardware, and sits between the operating system, database engine and the users. The hardware needs to be provided by the project.
At the user end it is a platform that sits between the operating system, the servers and the user allowing specially written applications to run on the data provided from the project's servers. The hardware used by the client is provided by the user.

boboviz wrote:

In which way they "hinder" the project?

Well, as you know, Jacob Klein posted in reply to the post from Stefan that I quoted - asking many of the same questions that Rob Smith has just hinted at. Neither has posted since, so we are - as so often - working somewhat in the dark.

BOINC actually consists of three parts:

• the server code
  
• the client code (and, separately, manager)
  
• the API code which is compiled and linked with project science applications
  

There are issues with all three which could fit the pattern of complaints from both users and administrators at GPUGrid. Some examples:

1) Server code - is responsible for allocating tasks to users in response to host requests. GPUGrid have multiple applications, to suit the wide range of GPUs and drivers encountered 'in the wild'. They may - and this is speculation on my part - find that the server administration tools make it hard to match applications to hosts.

2) Client code - doesn't report separately the capabilities of multiple, different, GPUs installed in the same host. That makes (1) almost impossible to achieve in practice. I heard David Anderson admit that this was a design error, in his talk at the BOINC workshop in Budapest, September 2014. No timetable has been published for fixing this.

3) API - hasn't been fully updated to address the multithreading models of Windows 7 and Windows 10, which can lead to timing problems - such as the delay in suspending the latest GPUGrid v9.18 application when requested by BOINC. Code version control is particularly bad (i.e. non-existent) in the API branch.

Poor design decisions, poor version control, and poor communication between supplier (BOINC) and consumer (project scientists), are all ways in which an infrastructure provider can 'hinder' use of their platform. I doubt it applies to BOINC alone.

Poor design decisions, poor version control, and poor communication between supplier (BOINC) and consumer (project scientists), are all ways in which an infrastructure provider can 'hinder' use of their platform. I doubt it applies to BOINC alone.

We are off topic, but....
- A "little" difference between boinc and gpugrid. Boinc is open source, gpugrid not. So, if gpugrid admins want, they can partecipate to development of the functions they need. If there are bugs in gpugrid code, boinc admins cannot see these. Simple.
- If gpugrid dudes are not satisfy about boinc, they can go out. With 6/7 milion dollars they will buy a little hpc server and work with this. Ah, they do not have all this money? Ah, boinc is for free?
- Not to be listened by boinc's admins is like a Dante's "contrappasso": gpugrid admins don't listen their volunteers. :-P

GPUGrid have multiple applications, to suit the wide range of GPUs and drivers encountered 'in the wild'.

Are you kidding? Gpugrid supports ONLY Nvidia gpu (and ONLY a subset of these gpu - recent medium/high end gpus).
A lot of projects support cpu (intel and amd), gpu (intel, nvidia and amd), android, raspberry, etc at the same time.

P.S.
Another way is possible: like Folding@Home. They can create their "ecosystem", with their needs satisfied

Close the off-topic line.

Their role, like all projects, is to get science done - in their case, complicated and time-consuming science. It isn't their role to provide work for volunteers who offer resources which are unsuited to their needs - other projects are available for that.

We disagree, so I accept that we should close this side-discussion.

Not to be listened by boinc's admins is like a Dante's "contrappasso": gpugrid admins don't listen their volunteers. :-P

this, unfortunately, is very true :-(
One can observe this day by day when reading in their forum.