Is Boinc too complex for the average computer user?

Since it's inception Boinc has tried to be the one tool you need for DC computing. Trouble is many, many newcomers seem to have all sorts of problems getting Boinc to work in the manner they want. Complaints range to include most anything from..........

The Screensaver don't work. The Boinc screensaver has never worked on all machines. The Boinc screensaver is dependant in the implemenataion of OpenGL in each machines video drivers. Some implementations work better than others. Pleas to bring back the old screensaver have fallen on deaf ears. But why not bring it back? The old one just worked and everyone knows that if they use the screensaver they will take a performance hit on processing work units. So why not scrap the OpenGL concept and go back to the original screensaver? Using the old screensaver could be highly desirable in the old (advanced years?) Seti community!

My project X stopped crunching, and I made no changes to the system. Actually this covers a multitude of problems all concerning Boinc's configuration. First question a helpful user asks is "are you using the web configuration or a user override file?" The usual response is "HUH?". IMHO the configuration of Boinc is overly complex and then add the ability to override the web preferences with a local override file is doubling or trippling the problems. Now add to this the fact that some settings work on the web configuration but not in the override file. Or maybe the other way around. Result is a new user who is confused and simply removes Boinc from his system which is NOT the desired outcome. I must add here that if the default settings are used Boinc will run very well. It's when a new user starts to "adjust" his system that most problems occur and a lot of tinkering happens trying to get the Seti screensaver to work.

Don't get me wrong, I love Boinc and only crunch data for Seti. In my ideal world there would be about 10 full time Boinc/Seti programmers and a budget that would allow buying ALL the latest hardware their little hearts could want or need. In this world we have to settle for less. The people who have brought us Boinc and Seti have done a wonderful job and I want them to continue. I don't want this project to fail but these problems described above have been happening for much too long.

Is Boinc too complex for the average computer user?

Since it's inception Boinc has tried to be the one tool you need for DC computing. Trouble is many, many newcomers seem to have all sorts of problems getting Boinc to work in the manner they want. Complaints range to include most anything from..........

The Screensaver don't work. The Boinc screensaver has never worked on all machines. The Boinc screensaver is dependant in the implemenataion of OpenGL in each machines video drivers. Some implementations work better than others. Pleas to bring back the old screensaver have fallen on deaf ears. But why not bring it back? The old one just worked and everyone knows that if they use the screensaver they will take a performance hit on processing work units. So why not scrap the OpenGL concept and go back to the original screensaver? Using the old screensaver could be highly desirable in the old (advanced years?) Seti community!

My project X stopped crunching, and I made no changes to the system. Actually this covers a multitude of problems all concerning Boinc's configuration. First question a helpful user asks is "are you using the web configuration or a user override file?" The usual response is "HUH?". IMHO the configuration of Boinc is overly complex and then add the ability to override the web preferences with a local override file is doubling or trippling the problems. Now add to this the fact that some settings work on the web configuration but not in the override file. Or maybe the other way around. Result is a new user who is confused and simply removes Boinc from his system which is NOT the desired outcome. I must add here that if the default settings are used Boinc will run very well. It's when a new user starts to "adjust" his system that most problems occur and a lot of tinkering happens trying to get the Seti screensaver to work.

Don't get me wrong, I love Boinc and only crunch data for Seti. In my ideal world there would be about 10 full time Boinc/Seti programmers and a budget that would allow buying ALL the latest hardware their little hearts could want or need. In this world we have to settle for less. The people who have brought us Boinc and Seti have done a wonderful job and I want them to continue. I don't want this project to fail but these problems described above have been happening for much too long.

I've made your second argument in the past, and for the most part, the vocal users seem to want their knobs to twist and buttons to push.

In my opinion, we'd do nicely if BOINC started with a 1 hour cache, and added an hour for each consecutive day of crunching, up to a 4 or 5 day limit.

The total cache size (max. 5 days) can then be divided by the number of projects (since two projects make it twice as likely that one will be operating).

... and that's that.

The complexity you're noting is there because people said things like "three venues (on the web configuration) aren't enough!" and "I need more cache!"

My counter argument though is that the average user does not do anything to make BOINC crunch "the way they want" because the average user installs BOINC, and is done. If someone is trying to get "more" out of BOINC, they're already past "average" and into advanced.

---

The Screensaver don't work. The Boinc screensaver has never worked on all machines. The Boinc screensaver is dependant in the implemenataion of OpenGL in each machines video drivers. Some implementations work better than others. Pleas to bring back the old screensaver have fallen on deaf ears. But why not bring it back? The old one just worked and everyone knows that if they use the screensaver they will take a performance hit on processing work units. So why not scrap the OpenGL concept and go back to the original screensaver? Using the old screensaver could be highly desirable in the old (advanced years?) Seti community!

It is to my understanding that OpenGL was chosen because of its cross platform compatibility. The old screen saver had to be rewritten for every platform, which caused a lot of extra time spent simply making the graphics work. If there's a way to rewrite the old screen saver (an exact replica if possible) using OpenGL, I think that would suffice.

---

IMHO, when installing BOINC, as part of the install if all the basic options or preferences settings would come up to be managed then... instead of looking around for something a new user does not know exists when they have problems or don't like something on their computer that is happening ( quad cores processing on 2 cores only, internet connection frequency, other programs lag etc...) might help. Additionally, I whole heartedly agree with Ned's initial cache intentions, but as this has been cussed and discussed many times in my short tenure I see little that can be done.. the 3000 to 5000+ WU's waiting on a computer that amounts to...what was that, 37 years worth of WU's and getting more daily, needs to be addressed. All in all this is a well needed thread that hopefully a good idea or two might come out of it and be implemented.

IMHO, when installing BOINC, as part of the install if all the basic options or preferences settings would come up to be managed then... instead of looking around for something a new user does not know exists when they have problems or don't like something on their computer that is happening ( quad cores processing on 2 cores only, internet connection frequency, other programs lag etc...) might help. Additionally, I whole heartedly agree with Ned's initial cache intentions, but as this has been cussed and discussed many times in my short tenure I see little that can be done.. the 3000 to 5000+ WU's waiting on a computer that amounts to...what was that, 37 years worth of WU's and getting more daily, needs to be addressed. All in all this is a well needed thread that hopefully a good idea or two might come out of it and be implemented.

Dennis,

My suggestion for cache size is based on the idea that we don't know how much time the machine is on or what the duration correction factor should be on that first work fetch. Capping the cache size early prevents problems caused by an early error.

So would simply setting the initial Duration Correction Factor to 10 or more.

Your comment about the machine that fetches 3,000 work units or more is a different issue. It is some sort of bug, and it's probably related to some non-obvious flaw on this particular computer.

I think it was seen at least once in a school computer lab where the machines were routinely "wiped" of any transient files (like work units).

Keep in mind that when this has been (as you say "cussed and") discussed, most people say "oh, no, if they take away my ability to tweak, I'll quit!" or even "it's doing the wrong project, how dare they take control of my computer!"

The vocal users who drive alot of these decisions want 100% manual control. The majority are fine on 'autopilot'....

-- Ned

P.S. I disagree with the idea that the new user should be given things to tune. My statement is that tuning should be difficult at best, and good defaults are more than adequate.

---

My statement is that tuning should be difficult at best, and good defaults are more than adequate.

That's what made SETI Classic so successful. One of the major complaints I hear against BOINC is that it's too complex for average users. Most of them should simply use the defaults, but they see all sorts of options and they think BOINC requires manual configuration, else they simply "see buttons and must press them".

I think a different way to do things would be to make it so there are no options to change within BOINC, or on the website. The default installation should have the most project-safe settings and always err on the side of caution. Then, for advanced users, it should be possible to manually create a file placed in your BOINC folder that can modify it's behavior. Since advanced users have no problems creating their own .INI file with boolean settings, this would limit who changes what in BOINC. Then, good documentation for each allowable setting within the configuration (in my example, an .INI file) file can be provided by either an included CONFIG.TXT file or an online Wiki.

This would help streamline BOINC and protect it from adventurous novices who want to max out all settings because it "seems" like a good idea, and make it much easier to run like SETI Classic was.

---

I think the Simple/Advanced view options have gone a ways to making BOINC 'simpler'. If the Advanced view looks scary, you just go back to simple.

Maybe Advanced view should only be accessible by a "ctrl-F7" or other 'unlocking' mechanism, found easily in the documentation if you want, but obviously not required (to the novice user - if I need to unlock it, I don't really need it).

---

Crunching SETI@Home as a member of the Whirlpool BOINC Teams

Should the configuration be made as part of the installation of BOINC, using Q & A?
E.g. Is your internet connection via dial-up or broadband?
If answer is dial-up, then questions on frequency of connections, as required/always ask/once per day etc.

Then explain BOINC projects are NOT commercially run and server downtime or no work available is to be expected, so joining two or more projects is advised.

When attaching to a project, ask how much resources to be given to new project, show list of present attached projects and their % of resources. Use slider bars and direct number i/p to set shares.

If users then insists on only joining one project, then set work cache to x days but explain this will not be immediate as performance of computer and its habits are unknown and that work cache has to be earned by reliably returning tasks.
Then allow increase in work cache to be in line with increase in RAC. Therefore it will probably take a month before work cache is up to full size.

"If users then insists on only joining one project, then set work cache to x days but explain this will not be immediate as performance of computer and its habits are unknown and that work cache has to be earned by reliably returning tasks.
Then allow increase in work cache to be in line with increase in RAC. Therefore it will probably take a month before work cache is up to full size."


Now that is one great suggestion.

---

Should the configuration be made as part of the installation of BOINC, using Q & A?
E.g. Is your internet connection via dial-up or broadband?
If answer is dial-up, then questions on frequency of connections, as required/always ask/once per day etc.

Now this might be a solution. And perhaps since the project is short on programers some kind soul could take it upon themselves to create an executable asking questions and answers. Store the results in a user override file and stop/restart Boinc if it's running so as to read the file. One of the first questions should be "Do you want to make use of the Boinc Screensaver?"

[edit]Have an explanation of the pros and cons of each setting as you progress through the questions and answers![/edit]

"If users then insists on only joining one project, then set work cache to x days but explain this will not be immediate as performance of computer and its habits are unknown and that work cache has to be earned by reliably returning tasks.
Then allow increase in work cache to be in line with increase in RAC. Therefore it will probably take a month before work cache is up to full size."


Now that is one great suggestion.

I second that notion. Especially seeing as that gives the DCF a chance to settle in and be able to provide the real amount of work necessary to match the actual setting. Kinda like allowing newbies to get their feet wet before jumping in whole hog. That should even avoid a lot of dropped WU's when the newbie gets "ascared" because their system just downloaded 300 WU's and just deletes the whole kit-and-kaboodle! I know I've seen a few Wingmates that look like that's just what they did.

Could there also be some additional logic put in initially that adjusts the DCF right out of the gate? So it's a closer approximation of reality? I know that my Quad PIII-500 Mhz still has a .456 DCF, so 1.00 sounds a bit high for common systems these days. All of my even semi-recent vintage systems clock in at roughly .30. Is 1.00 still referring to something classed as the bare minimum? (Not to imply insult to anybody running a system with a DCF > 1.00 :-)) Even my P4 1.8 Ghz ranks in as a .321163 DCF...

---

"If users then insists on only joining one project, then set work cache to x days but explain this will not be immediate as performance of computer and its habits are unknown and that work cache has to be earned by reliably returning tasks.
Then allow increase in work cache to be in line with increase in RAC. Therefore it will probably take a month before work cache is up to full size."


Now that is one great suggestion.

I second that notion. Especially seeing as that gives the DCF a chance to settle in and be able to provide the real amount of work necessary to match the actual setting. Kinda like allowing newbies to get their feet wet before jumping in whole hog. That should even avoid a lot of dropped WU's when the newbie gets "ascared" because their system just downloaded 300 WU's and just deletes the whole kit-and-kaboodle! I know I've seen a few Wingmates that look like that's just what they did.

Could there also be some additional logic put in initially that adjusts the DCF right out of the gate? So it's a closer approximation of reality? I know that my Quad PIII-500 Mhz still has a .456 DCF, so 1.00 sounds a bit high for common systems these days. All of my even semi-recent vintage systems clock in at roughly .30. Is 1.00 still referring to something classed as the bare minimum? (Not to imply insult to anybody running a system with a DCF > 1.00 :-)) Even my P4 1.8 Ghz ranks in as a .321163 DCF...

Actually, that was a big part of my suggestion in the second post on the thread, limit the cache early and give us time for the Duration Correction Factor (and the percent-crunching value) to settle.

I don't think DCF has anything to do with clock speed. It has to do with the difference between the predicted time and the actual run time of some real work. It has to adjust across multiple work units to be representative.

One really simple way to prevent an overfetch early would be to start with a DCF of 10 or so, but that might scare a new user due to the extremely high predicted duration that'd cause.

---

A DCF of 2 would probably be sufficient, and with a carefully worded explanation most concerns of long estimates could be overcome. Something like;

The estimated completion time for the first tasks downloaded will be high, possibly by as much as 10 times the actual processing time. The estimated time should be approximately correct after 25 units have been completed.

A DCF of 2 would probably be sufficient, and with a carefully worded explanation most concerns of long estimates could be overcome. Something like;

The estimated completion time for the first tasks downloaded will be high, possibly by as much as 10 times the actual processing time. The estimated time should be approximately correct after 25 units have been completed.

Assuming of course that users read.

---

A DCF of 2 would probably be sufficient, and with a carefully worded explanation most concerns of long estimates could be overcome. Something like;

[...]

Assuming of course that users read.

Unfortunately, you've got to overcome the automatic reaction of many people to instantly 'click-away' any and all dialog boxes/pop-ups. No thought there, let alone even the start of doing any reading.

I guess a certain OS has taught most users that any pop-up message will be arcane and unintelligible and just delays startup and it'll work regardless, so "just click it away and continue".

Rather bad for creating a jaundiced view and for making people resistant to learning about the OS. Then again, it does mean that the programmers must make things simply work on defaults only...


I agree that having gentle start-up parameters for the DCF and cache are a good idea until whichever new host has 'settled down'. Propose it on the developers list?

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

A DCF of 2 would probably be sufficient, and with a carefully worded explanation most concerns of long estimates could be overcome. Something like;

[...]

Assuming of course that users read.

Unfortunately, you've got to overcome the automatic reaction of many people to instantly 'click-away' any and all dialog boxes/pop-ups. No thought there, let alone even the start of doing any reading.

I guess a certain OS has taught most users that any pop-up message will be arcane and unintelligible and just delays startup and it'll work regardless, so "just click it away and continue".

Rather bad for creating a jaundiced view and for making people resistant to learning about the OS. Then again, it does mean that the programmers must make things simply work on defaults only...


I agree that having gentle start-up parameters for the DCF and cache are a good idea until whichever new host has 'settled down'. Propose it on the developers list?

Happy crunchin',
Martin

Hi Martin,

It's more than just a "kinder, gentler" startup.

People have complained for years that "connect every 'x'" did too many things: it told BOINC how often internet access might be available, and it controlled cache size -- if you wanted a big cache, you were forced into a big connect interval.

Now we have "extra days" which splits the two functions somewhat.

What I'm really advocating is the elimination of both parameters.

Why? Because they cause the kind of "complexity" complaints that are the root of this thread. You can set "connect every 'x' days" and "extra days" to 10 and get 20 days worth of work -- probably with impossible deadlines.

That forces more work units to need "priority" and that generates complaints about BOINC not following resource shares (even though it will, eventually).

So, in place of that, we put in some simple calculations. Set connect every 'x' to 0.5 and nail it there. Make the "extra days" 5/n, where n is the total number of projects (crunch 2 projects, and carry a 2.5 day cache, crunch 10 projects, your cache will be 1 day). You'll have work as long as one of your projects is up during the cache time.

The only place this doesn't work is for someone who has intermittent access to the net, but there is probably a way to work around that.

But, here's the rub. We can't demand more features and better control, and then complain that BOINC is complex because there are too many features and controls.

Sorry, I'll get off my soapbox now.

-- Ned

---

But, here's the rub. We can't demand more features and better control, and then complain that BOINC is complex because there are too many features and controls.

Oh, but "we" can and "we" will... ;-P

As I mentioned in my prior post on this thread I believe Geek@Play put forth a good question that hopefully a good idea or two will be brought up and implemented... so Ned I respectifully ask you to please stop throttling the ideas put forth with why things won't work or how average guy does this or that. Let the ideas come forth, and Geek and his/her post and the upper SETI food chain figure it out and possible working solutions. I apologize for any offense or trespass, I am an old man blessed by still working around young minds with great ideas almost daily, on advanced military aircraft. I see the benefits of ideas brought out and one or two good ones make all the difference. /salute

I guess a certain OS has taught most users that any pop-up message will be arcane and unintelligible and just delays startup and it'll work regardless, so "just click it away and continue".

Yes but I think you will agree that the "default" is not usually wrong (or it can autodetect the proper value to use). In this case, the default values usually (I emphasize "uaually") will satisify the "Classic SETI" user, it might be useful to ask if you are a "power user" or a "normal user". In this case, if they answer "normal" then it's installed with the generic options. If they answer "power user" or something to the like, then they can be told through an instruction sheet where to find and adjust the proper settings.

Rather bad for creating a jaundiced view and for making people resistant to learning about the OS. Then again, it does mean that the programmers must make things simply work on defaults only...

Yes again, but there should be some "smarts" involved in the install process to detect the kind of connection the person has, possibly pinging the servers at install time, and at various other times to check if the default connection cannot be maintained... but there again the program has to be "smart" enough to detect the difference. Really too complicated unless you are wanting to "rule the world through your program" (as a certain OS believes) and have the development of the system capable of adapting to any changes. Otherwise leave the defaults set as they are as they seem to work with most new users. But it might be nice to include a notice when installing at least where to find out how to change the defaults. Possibly by a checkbox that pops up during an install to tell them that they are installing with the defaults and where to find the info to change them before proceeding. They must agree that they understand this info before the install will complete. This might eliminate a lot of complaints.

I agree that having gentle start-up parameters for the DCF and cache are a good idea until whichever new host has 'settled down'. Propose it on the developers list?

Happy crunchin',
Martin

Hi Martin,

It's more than just a "kinder, gentler" startup.

People have complained for years that "connect every 'x'" did too many things: it told BOINC how often internet access might be available, and it controlled cache size -- if you wanted a big cache, you were forced into a big connect interval.

Now we have "extra days" which splits the two functions somewhat.

What I'm really advocating is the elimination of both parameters.

Why? Because they cause the kind of "complexity" complaints that are the root of this thread. You can set "connect every 'x' days" and "extra days" to 10 and get 20 days worth of work -- probably with impossible deadlines.

That forces more work units to need "priority" and that generates complaints about BOINC not following resource shares (even though it will, eventually).

So, in place of that, we put in some simple calculations. Set connect every 'x' to 0.5 and nail it there. Make the "extra days" 5/n, where n is the total number of projects (crunch 2 projects, and carry a 2.5 day cache, crunch 10 projects, your cache will be 1 day). You'll have work as long as one of your projects is up during the cache time.

The only place this doesn't work is for someone who has intermittent access to the net, but there is probably a way to work around that.

But, here's the rub. We can't demand more features and better control, and then complain that BOINC is complex because there are too many features and controls.

Sorry, I'll get off my soapbox now.

-- Ned

Yes I agree that it is sorta complicated, but I feel like a simple popup/dialog box would solve a lot of problems. Let the dialog box tell the user what the defaults are and if they want to agree to installing with those then click ok, if not they will be sent to a page that explains where to find and change the defaults and the meanings of each. (This last part could be made part of the dialog box also.)
This will let them know that they can change the default behaviour but they don't have to for it to run properly. This should be simple enough for any decent programmer to create but it would have to be done for every OS as each uses different script languages, etc.
Basically to me, it would be a simple script that explains the default installation, and instructions on how to change them if wanted. No need for changing the defaults then-and-there. More "education" and less hassle.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

One idea that I like that I don't see mentioned in this thread, is set the quota to 1 for new hosts. That way the host can download enough work to get started, but cannot download more until some is returned. The max quota would be the same and would be quickly reached if the host is working properly. However there would still be problems with new participants worried about their queue filling.

---

BOINC WIKI

BOINCing since 2002/12/8