and yes, i agree, simple is nice and easier, but it doesn't fit the needs of most projects now, which is clear as many are moving to BOINC, and simple doesn't always mean better

Actually, *I* think one of the main reasons that projects are moving to BOINC is that it is substantially cheaper in that a huge amount of the infrastructure is already done. So, they do not have to reinvent the wheel.

*I* like it as a participant because I can add new projects as they come on line. At the moment I am running 7 different projects across my "farm" and loving life. One of my biggest hang ups in the dark ages was that I could not do more than one project per computer ... now, I have choice ... and in the not to distant future, well, I will have too many projects to choose from ...

Oh of corse, from a purely "project" point of view, I entirely agree. I was just pointing out that the new features BOINC offers helps in the decision as well :) and we don't end up with the current SETI@home classic problem of being 50+ million results behind in the validation queue

@Paul
You forgot the point that a new project has a good opportunity for targeted advertising. By using BOINC and going around to all the current projects, getting mentioned in the wiki, and getting mentioned on the BOINC homepage, they can advertise to a group of people known to be willing to donate CPU time.

@Aaron
Most of the preferences are automatically scaled to the host. That is one of the reasons the work buffer is set in days rather than in work units, for example. This makes web settings a bit more sensible and per host settings less needed than they would appear at first glance. However I still support being able to set them in the client and possibly even for individual hosts.

@participants leaving
Please try again when version 5.2.x is released. The need to worry with the authenticator is gone, an email and password system has mostly hidden it from the participant. The URL is still needed for telling the client which project to work on, but even that is in the process of being hidden to a certain extent as well.

---

BOINC WIKI

BOINCing since 2002/12/8

Perhaps this is only a CP.net issue, but it obviously wanted GBs. I set it to 0.2GB, as that seems more than reasonable for an individual contribution.

Hi,
CPDN need at least 700 MB to complete a slab model. If you've only allowed 200MB, your model will simply crash.
Use at least 1Gb for slab and 2.7 Gb for a sulphur model.
@+

It will just crash? Sorry but that may be okay for a student project, but not for 'real world' software. When I allocate on disk work space I should be told that it's too small, or failing that when I attach a project that needs more space I should be told then. Not wait a few hows for a application crash!

---

It will just crash? Sorry but that may be okay for a student project, but not for 'real world' software. When I allocate on disk work space I should be told that it's too small, or failing that when I attach a project that needs more space I should be told then. Not wait a few hows for a application crash!

Ah, but this is not "real world" software, what ever that means. All Microsoft Windows versions crash. I used to be able to crash OS/2 until Warp SP4, I can crash OS-X "Tiger" ...

Yes it would be nice, and it would be better to warn the participant before hand that their system is not adequate to the needs. Some of the pending software updates are in the queue to address some of these issues.

But, fundamentally, the point is to try to do science with the lowest cost possible. I have not heard of any DC project that has any significant programming staff. The "usual" staff level is one or two developers for all of the project code, and they are also responsible for the care and feeding of the server-side components too ...

@JKeck, yes, that is true ... I just started two new projects last week but only on a couple of my systems. I expect that this will be more my model, with some projects only running on one or two systems... but, the community attraction is one of the strong points of BOINC ... you can see that with the eagerness and joy when a new project is on-line.

---

I get confused with the bytes, k bytes, meg, gig and well you get the idea. Now CPDN states that the minimum disk storage is 600kb, now isn't that 0.6meg and if you only give it 0.2gig, you have strangled the WU on takeoff and it will crash and burn, soon not later..... I am really confused now.......

---

BOINC Wiki

I'm not sure where you read the kilobytes, Jim, but CPDN's Recommended System Requirements state 600MB available disk for all computers...

---

I'm not sure where you read the kilobytes, Jim, but CPDN's Recommended System Requirements state 600MB available disk for all computers...

Told you I was confused lolol

---

BOINC Wiki

As far as i know it's something around 80% of people have only 1 host, but if you compare the total number of hosts in the "1 host/user" group and "2+ hosts/user" group it's a lot closer to 50% (something like 40% of hosts are part of the "2+ hosts/user" group) and this represents a large majority of crunching power (see point further below)

Those numbers don't surprise me in the least. You do realise that this means that for 80% of your users, you just made BOINC unnecessarily confusing.

The "set locally and transfer to the web" really seems the best way to go. Taking this a step further, the transfer to the web needs to be an option.

I'm a refugee from Find-a-Drug, so when that closes down Dec 16, I'll be bringing four machines over to BOINC (maybe more). However, only two of these systems will share config data. My desktop at home and my wife's will share settings, but my notebook and my work system must necessarily use different configs. Why do I even need to have those two configs on the web?

I just feel that by having them as part of the app and not web based (and so won't propogate to all hosts) it is not worth the hastle for the people for multiple computers comapred to the slight increase in conviencince for a single-host user ... as most of the big crunchers (who do a vast majority of the work for projects) have *lots* of computers, and i'm sure many would be put off by app only prefs (imagine having to update 30-40 computers!!)

Right. 30-40 host users really need the web setup. However those folks are generally sufficiently well acquainted with the project that they know where to go to set web settings.

You know what I'd do?

Create a local config screen. Make sure it has two extra items:

Firstly a checkbox & edit field (default unchecked and empty) that optionally allow you to save the config to the web.

Secondly a dropdown list that can optionally allow you to load the config from a previously saved setting.

If you really care that much about the 30-40 host users, and don't care about the single computer users, then say so. Make it clear that BOINC is targetted at people who can bring large farms of systems online, so that single computer people who don't have enough "crunch power" to be considered worthwhile will know to look elsewhere.

You may not like my last statement, but sadly, that's the impression you create.

---

dgnuf,

You do realize that none of the poeple you have been "talking" to are actually project people, don't you?

"We", as a group, try to help people understand the strengths, and weaknesses, of BOINC. But, other than submitting suggestions, or developing material/code on a volunteer basis, we are just as much an outsider as you.

So, you have a point, and we have asked for the local settings before, but, and until, either UCB gets time, or someone develops this on their own and submits it for use, well, on-line settings are what we have ...

---

Drat! duplicate!

---

Those numbers don't surprise me in the least. You do realise that this means that for 80% of your users, you just made BOINC unnecessarily confusing.
The "set locally and transfer to the web" really seems the best way to go. Taking this a step further, the transfer to the web needs to be an option.
I'm a refugee from Find-a-Drug, so when that closes down Dec 16, I'll be bringing four machines over to BOINC (maybe more). However, only two of these systems will share config data. My desktop at home and my wife's will share settings, but my notebook and my work system must necessarily use different configs. Why do I even need to have those two configs on the web?

BOINC is trying to be many thing to many people, that is the idealology, obviously it's not that easy to do in practice, as the more general purpose something tries to be, the less good it is in each area, so it's not going to be perfect for any particular group of users.

I am not saying that any 1 group is more or less important to a project, only that by implementing some of the previosly suggested "solutions", a lot of people, with a lot of processing power will be turned away, however that doesn't mean that people with less crunching power should be excluded under the premise that "they don't matter so much" as i expect that comparing crunchers to normal users (farms vs single hosts) that the spread of work is about 50% for each group as there are lots of single-host users out there.

It is possible to have different prefs for different computers under the same account, just use the "venues" feature. I have made the suggestion myself to allow users to create their own venues, and as many as they need, so that, if needed, there are seperate prefs for each computer if needs be, rather than being stuck with just 4 (default, home, work, school).

Right. 30-40 host users really need the web setup. However those folks are generally sufficiently well acquainted with the project that they know where to go to set web settings.

I agree in general, but there are people with lots of hosts who just want things to be simple, and that's what the web based prefs does for them, imagine a company who wishes to donate out of hours CPU time, all they have to do is distribute a standard package which will automatically attach the client to the desired project(s) under one account (for each project) and all preferences just have to be changed on the website, and they'll propogate to all hosts, wonderful :)
However i'm not saying that single host users shouldn't have a relatively easy method for their own needs, and one of the previously suggested solutions would serve well IMHO.

You know what I'd do?
Create a local config screen. Make sure it has two extra items:
Firstly a checkbox & edit field (default unchecked and empty) that optionally allow you to save the config to the web.
Secondly a dropdown list that can optionally allow you to load the config from a previously saved setting.

this seems like it will just complicate things even further, and those that understand web-based self-propogating prefs will have to re-learn how the system works to properly understand how to set things. However i'm sure some half-way point could be reached.

If you really care that much about the 30-40 host users, and don't care about the single computer users, then say so. Make it clear that BOINC is targetted at people who can bring large farms of systems online, so that single computer people who don't have enough "crunch power" to be considered worthwhile will know to look elsewhere.
You may not like my last statement, but sadly, that's the impression you create.

It's not that I care more or less about one group or another, as said before, BOINC is trying to be many things to many people, and suggestions and comments will make it better :) and as paul kindly stated, we're only users like yourself, and have little direct influence on the project. We can only make requests, the best place to do that is in these BOINC forums.

My appologies in that case, that is/was not my intent, I was merely trying to point out the other point of view, however I suppose my view is biased towards web-based, as I've crunched for classic for many years (from mid-2000) and *I personally* find web-based much easier as i have many hosts, but i am sympathetic to the needs and wishes of single-host users, and do not wish to exclude them.

You know what I'd do?
Create a local config screen. Make sure it has two extra items:
Firstly a checkbox & edit field (default unchecked and empty) that optionally allow you to save the config to the web.
Secondly a dropdown list that can optionally allow you to load the config from a previously saved setting.

this seems like it will just complicate things even further, and those that understand web-based self-propogating prefs will have to re-learn how the system works to properly understand how to set things. However i'm sure some half-way point could be reached.

If we're willing to make one change to what I originally proposed, it can continue to work as is for your 30+ host users. You maintain the web interface, and if no configuration is selected locally use the web one.

So current idea becomes basically "use web config if it's there, otherwise use local if it exists, otherwise fall back to default settings."

A fundamental of good design is that you don't surprise the user. This means that it is a given that the current system for your 30+ host users must continue to function. The problem is that the current system DOES surprise casual users, because I think we all agree that the current web based config setup is extremely unusual. Take a look at every other program you have installed on your machine, and find one that does not have local access to configuration setting.

Let's see what happens in both cases, given what I'm suggesting.

30+ host user: Head for web, he knows that's where he sets options. Set them up. Install and go. Machines automatically slurp down the web options if they're there. Since they are, it's business as usual.

Joe User: Install and run. No options are set on the web. Assuming the existance of intelligent defaults, program runs with no further interaction. If something DOES need tweaking, you can bet the first place they'll look is under the Options menu of Boincmgr.

Who loses in this scenario?

---

If something DOES need tweaking, you can bet the first place they'll look is under the Options menu of Boincmgr.

Simpler fix - put an "options" item in the menu, but have it link out to the preferences page of the first project they attached to...

---

Regarding the preferences issue, my gripe is that I can't adjust all my projects from the one page - I have to log in to SETI, CPDN, Predictor etc to adjust my ratios... surely there should be a central prefs page (either each projects co-hosts for everyone, I don't know) where you have your list of projects, and can do everything in just one page visit.
If you then wanted advanced prefs (disk space, or whatever) that were project specific, then you could go to another page for that project.
As is, while I understand the logic, it can be a bit cumbersome.
edit: Also, since the "venues" options are not easily user accessible at present, why not just ditch them and simplify the whole preferences form in the meantime? It's a great idea, but I at least have found it too annoying to administer. If you could set it up as a startup switch (-home, -work) or as an option in the manager, rather than mucking about with xml files that would be great...)

---

Regarding the preferences issue, my gripe is that I can't adjust all my projects from the one page - I have to log in to SETI, CPDN, Predictor etc to adjust my ratios... surely there should be a central prefs page (either each projects co-hosts for everyone, I don't know) where you have your list of projects, and can do everything in just one page visit.
If you then wanted advanced prefs (disk space, or whatever) that were project specific, then you could go to another page for that project.
As is, while I understand the logic, it can be a bit cumbersome.

This kinda stuff is comming with "account manager" sites, the reason they're all seperate is just that, to keep them seperate, so that projects are independant, that was one of the primary aims of BOINC.

edit: Also, since the "venues" options are not easily user accessible at present, why not just ditch them and simplify the whole preferences form in the meantime? It's a great idea, but I at least have found it too annoying to administer. If you could set it up as a startup switch (-home, -work) or as an option in the manager, rather than mucking about with xml files that would be great...)

trying to "co-host" or rather "link" projects, would be far too complicated to be worth it. how often does someone need to change their resouce shares anyway?
also you don't need to fiddle with xml files to change venues at all, it can be set per host, in the hosts area of "my account" (officially "view computers"), just view the host that you want to change, go to the bottom of the page, and change it there

trying to "co-host" or rather "link" projects, would be far too complicated to be worth it. how often does someone need to change their resouce shares anyway?
also you don't need to fiddle with xml files to change venues at all, it can be set per host, in the hosts area of "my account" (officially "view computers"), just view the host that you want to change, go to the bottom of the page, and change it there

I guess resource share is not changed often. If I change the venue though, I'm guessing I have to change it at all the projects that that computer is attached to... another case for central admin. However, I guess that the venue is also not changed often either.

Anyway, I should also point out that overall I think BOINC is a great idea and project, I'm just throwing in my ideas on what might make it better : )

---

trying to "co-host" or rather "link" projects, would be far too complicated to be worth it. how often does someone need to change their resouce shares anyway?

Since the settings seem to be incredibly pooched on a couple of projects, I need to hit the resource share on a fairly regular basis. I'd like to run LHC@home with about 10% share. However, it refuses to D/L work unless it's north of about 50%, the exact complaint is something to the effect that "I'm not going to D/L work because at 10% you won't be able to complete it in time."

This complaint is (of course) complete rubbish, since as I post this, the work that I did D/L has an expiration date of Sat 12 Nov (i.e. 5 days from now), and it's taken about an hour to do 16% of the work. Doing a quick number crunch, we get:

16% work in an hour means 6 hours to finish.
If the cpu is on it 10% of the time, that equates to 60 hours, or 2.5 days, meaning I could get about 2 WU done before expiration.

Do you begin to see the problem.

Same thing with disk settings. I have a system with about 75 MB of free disk space (it's an old box with 2K on it, 300 MB HD IIRC). Boinc simply WILL NOT D/L work to this system, claiming "there's not enough disk space". Never mind the fact that the entire contents of the BOINC folder on my desktop system is a whopping 29 Mb. What I actually do to D/L work, is to copy the folder to my desktop, kill the installed version of Boinc, fire up the version in the copied folder, D/L work, and then reverse the process.

Why is this shenanigans necessary, when the empirical evidence clearly shows that 75MB is plenty enough to D/L and run Boinc WU's from the sites I'm visiting? Granted, the Climate prediction site is not an option, it's known to have big WU's. But that's still not an excuse for the ones that are smaller.

also you don't need to fiddle with xml files to change venues at all, it can be set per host, in the hosts area of "my account" (officially "view computers"), just view the host that you want to change, go to the bottom of the page, and change it there

I suppose the idea of having a setting under "Options" called "Host" Is just way too confusing to all those 30+ host power users, right?

The logic that since this is a host specific setting, we set it on (gasp) the host, must be in some way be unsound. I just can't quite see where.

</sarcasm>

-- Edit -- Minor clarification --

---

I'd like to run LHC@home with about 10% share. However, it refuses to D/L work unless it's north of about 50%, the exact complaint is something to the effect that "I'm not going to D/L work because at 10% you won't be able to complete it in time."

This complaint is (of course) complete rubbish, since as I post this (snip)

Do you begin to see the problem.

Not going to argue the preferences issue, but on the above... No, I don't see the problem. You are trying to micromanage the resource share and say that "TODAY I want you to do LHC 10% of the time" - and BOINC won't do that. However, if you left it alone, the LTD would grow for LHC, and when it got high enough, it would download work. Over the LONG TERM, the project would get 10% of your resources - just as you told it to do.

---

I'd like to run LHC@home with about 10% share. However, it refuses to D/L work unless it's north of about 50%, the exact complaint is something to the effect that "I'm not going to D/L work because at 10% you won't be able to complete it in time."

This complaint is (of course) complete rubbish, since as I post this (snip)

Do you begin to see the problem.

Not going to argue the preferences issue, but on the above... No, I don't see the problem. You are trying to micromanage the resource share and say that "TODAY I want you to do LHC 10% of the time" - and BOINC won't do that. However, if you left it alone, the LTD would grow for LHC, and when it got high enough, it would download work. Over the LONG TERM, the project would get 10% of your resources - just as you told it to do.

The whole point is that I DON'T want to micromanage the resource share. I want to tell my system to do LHC 10% of the time. I'd like nothing better than to set it and forget it.

The problem is that because of quirks in BOINC's behavior, anything less than (empirically) 35% for LHC is effectively 0%.

Let me describe the problem again.

I WANT LHC to be 10%.

If I set LHC to 10% it refuses to D/L work.

To force LHC to D/L work, I have to "micromanage" the resource share.

Do you now see the problem?

---

Let me describe the problem again.

I WANT LHC to be 10%.

If I set LHC to 10% it refuses to D/L work.

To force LHC to D/L work, I have to "micromanage" the resource share.

Do you now see the problem?

If the main project is taking the other 90%, LHC will only download work when the main project is down and out of work.

There is no need for LHC to download work right now when it is used as a backup project, since neither the main project nor LHC can imagine when the main project will go down and have a long enough outage for an LHC unit to be able to be crunched within its deadline time.

So 35%, 10%, it doesn't matter if you leave it at a lesser percentage than the main project.

---