Morning all,

Has anyone been paying attention to the way Boinc is progressing? Payed attention to which way each decision was decided?

A super computer is basically a configuration of many processors controlled by a "Central command". Each processor is only capable of "doing what it's told". It has no real control of what it's asked to do or how it does it. A cluster is roughly the same. It is pretty efficient at processing work.

I think Boinc is trying to be more like this, and it's decisions (each decision) seems to be taking US more in that direction. It seems we (user input, user requests, and even the ability to make a decision) are being relinquished to obscurity with each decision. It's kind of like we are being told to be quiet, don't offer constructive criticism, and just crunch what we want you to, when we want you to crunch it. "Just be a good little processor"

I offer up these examples:

1) the new scheduler won't allow a cache of any size. It wants to be kept as close as possible to only having one WU at a time (just like a CPU in a Cluster). Now Boinc realizes that they need us, but only because we have a CPU for the cluster, so they have to make us happy to a "Minimal" extent.

2) We request an additional Cache setting in addition to the Connect to setting. We can't have that, because it gives the User (CPU) more control. Can't have that in an efficient computer.

3) We request an LTD page on our Boinc manager so we can examine more carefully what happens. Nope, if they have the ability to see what's going on they would be more likely to complain and that won't do.

4) We request a column sort feature (since 4.50,4.20) but we don't want to waste time on that as it gives users more control. We don't have time for that. "just crunch what we give you, the way we give it to you"

5) They remove the open/visible testing of new clients to the Alpha project. "This new scheduler is not going over exceptionally well, so let's hide it, then force it on them later, this will delay the complaints" "I wish we could make them more like a CPU" "We don't really want their input anyway, so Alpha is just right for 'central command'"

This is not a "Conspiracy Theory" thing, it's merely observations I've had about "why" they make each decision. Our/My usefulness here is becoming less and less and less with each decision.

Here's my guess about what's next:
1) Loose ability to select resource share.

2) Loose ability to pick projects

After that the only decision that we'll have left is:

Crunch or not crunch. "We'll make every other choice for you, You wanna help science don't you?"

Tony,

I think that your theories are way off the mark here
Have you subscribed to any of the mailing list Available I.E.
Boinc_Alpha or the Boinc_Dev Digests?

Many Boinc projects and Boinc has to work for all of them.

The Basic BOINC structure has to be functional for all projects and adding
user features has to be built on top of them.

I don't think the developers are ignoring any requests, It's a matter of designing the features and making sure they work for everyone..........



Respectfully,


Tim

---

Have you subscribed to any of the mailing list Available I.E.
Boinc_Alpha or the Boinc_Dev Digests?

Many Boinc projects and Boinc has to work for all of them.

The Basic BOINC structure has to be functional for all projects and adding
user features has to be built on top of them.

I don't think the developers are ignoring any requests, It's a matter of designing the features and making sure they work for everyone..........

No, I haven't subscribed to any of them, so judge my opinion accordingly. If we (boinc users) were nothing more than a CPU than that would be much easier to accomodate other projects. Would it not?

What would be so tough about a LTD page? Or a column sort feature? They've had months and months to provide a column sort. Don't they care? or is it because they know shortly we won't be needing it anyway?

It's just frustrating to watch them remove any need(other than that provided by our CPUs)for our participation.

---

No, I haven't subscribed to any of them, so judge my opinion accordingly.

Tony, I sincerely suggest that you subscribe to the Digests and read for yourself what is going on behind the scenes. It would help you form an opinion and you Can participate in the formulation of the projects, I know your Input would be welcome. Give it a try Tony...


Tim

---

Give it a try Tony...

I've sent you an email

I agree it is not a conspiracy theory, sounds more like paranoid to me.... We all have one option that no one can take away and that is to detach and disconnect.......

---

Semper Eadem
So long Paul, it has been a hell of a ride.

Park your ego's, fire up the computers, Science YES, Credits No.

Here's my guess about what's next:
1) Loose ability to select resource share.

2) Loose ability to pick projects

After that the only decision that we'll have left is:

Crunch or not crunch. "We'll make every other choice for you, You wanna help science don't you?"

I really doubt you'll ever loose the ability to choose what projects you wish to participate in. That would be the death sentence for BOINC.

As far as scheduling goes, once BOINC settled in on my PC, there was little difference in my operation of 4 constant projects and 1 occaisional project. The major change is if I want more work I now have to suspend everything but what I want to work on and it will pull in the full allocation for that project and then I can resume. For the most part I'm finding BOINC keeping enough WU's in place to continue crunching without interuption. I know it varies by how many projects you have, your cache settings, etc but as of this moment, it's meeting most of my needs.

I do agree with you though that user controled features are going by the wayside in favor of full automation. That I don't agree with. I really beleive that as they must cater to both the various projects as well as the two types of users (ones that like to tinker with settings and ones that don't like to tinker with settings), the programmers are stuck between trying to please everyone and that's just impossible.

---

To truly explore, one must keep an open mind...

Here's my guess about what's next:
1) Loose ability to select resource share.

2) Loose ability to pick projects

After that the only decision that we'll have left is:

Crunch or not crunch. "We'll make every other choice for you, You wanna help science don't you?"

I really doubt you'll ever loose the ability to choose what projects you wish to participate in. That would be the death sentence for BOINC.

As far as scheduling goes, once BOINC settled in on my PC, there was little difference in my operation of 4 constant projects and 1 occaisional project. The major change is if I want more work I now have to suspend everything but what I want to work on and it will pull in the full allocation for that project and then I can resume. For the most part I'm finding BOINC keeping enough WU's in place to continue crunching without interuption. I know it varies by how many projects you have, your cache settings, etc but as of this moment, it's meeting most of my needs.

I do agree with you though that user controled features are going by the wayside in favor of full automation. That I don't agree with. I really beleive that as they must cater to both the various projects as well as the two types of users (ones that like to tinker with settings and ones that don't like to tinker with settings), the programmers are stuck between trying to please everyone and that's just impossible.

The developers guess is that those that do not pay attention to their BOINC clients vastly out weighs those that do - therefore as much automation as possible is good.

The case for extra control has to be made well to get past Dr. Anderson. I am trying to get a split between queue size and connect interval.

As it stands, there is a way for those that want to try to micromanage their BOINC to do so (suspend is there, and is not as far as I know going away).

---

BOINC WIKI

John,

I have to somewhat agree with you here. My Unix systems are set to run. I do not babysit them like I do the two windows systems I have crunching. If I notice my RAC falling with SETI I will check the Solaris systems to ensure BOINC is still running.

Personally I like "install and let run" as long as I know it's running efficently. I can not trust that to happen with BOINC anymore.

The upgrade to 4.43 and quickly to 4.44 caused me to have to pay more attention to the two window systems.

If my PC is to be used as part of a mega-puter I want to be able to at the very least see what is being done with it and why.

---

I'd rather speak my mind because it hurts too much to bite my tongue.

American Spirit BBQ Proudly Serving those that courageously defend freedom.

John,

I have to somewhat agree with you here. My Unix systems are set to run. I do not babysit them like I do the two windows systems I have crunching. If I notice my RAC falling with SETI I will check the Solaris systems to ensure BOINC is still running.

Personally I like "install and let run" as long as I know it's running efficently. I can not trust that to happen with BOINC anymore.

The upgrade to 4.43 and quickly to 4.44 caused me to have to pay more attention to the two window systems.

If my PC is to be used as part of a mega-puter I want to be able to at the very least see what is being done with it and why.

The new scheduler is supposed to require less hand holding rather than more. There are still a few bugs to be shaken out. There are a couple of changes to policy that should be made as well.

As I see it, the main problems left in the scheduler as of 4.44 are:
Multi CPU systems not triggering EDF quite soon enough.
Download more work if CPU is idle broken.
Projects with a slight negative LT debt not able to get work (problem for modem users).
Minor problem with the LT debt calculations.
All of the above should be fixed in 4.45.

Remaining issue:
Connect time vs. queue time.

---

BOINC WIKI

As I see it, the main problems left in the scheduler as of 4.44 are:
Multi CPU systems not triggering EDF quite soon enough.
Download more work if CPU is idle broken.
Projects with a slight negative LT debt not able to get work (problem for modem users).
Minor problem with the LT debt calculations.
All of the above should be fixed in 4.45.

Remaining issue:
Connect time vs. queue time.

No Work Projects or Down Projects not affecting LTD of working Projects..

---

I'd rather speak my mind because it hurts too much to bite my tongue.

American Spirit BBQ Proudly Serving those that courageously defend freedom.

As I see it, the main problems left in the scheduler as of 4.44 are:
Multi CPU systems not triggering EDF quite soon enough.
Download more work if CPU is idle broken.
Projects with a slight negative LT debt not able to get work (problem for modem users).
Minor problem with the LT debt calculations.
All of the above should be fixed in 4.45.

Remaining issue:
Connect time vs. queue time.

I have to disagree with the EDF problem. On my system EDF occurrs the minute I download a unit with a deadline sooner than work in the queue. This results in einstein constantly being given priority over seti. I have to force it to run both simultaneously.

As I see it, the main problems left in the scheduler as of 4.44 are:
Multi CPU systems not triggering EDF quite soon enough.
Download more work if CPU is idle broken.
Projects with a slight negative LT debt not able to get work (problem for modem users).
Minor problem with the LT debt calculations.
All of the above should be fixed in 4.45.

Remaining issue:
Connect time vs. queue time.

I have to disagree with the EDF problem. On my system EDF occurrs the minute I download a unit with a deadline sooner than work in the queue. This results in einstein constantly being given priority over seti. I have to force it to run both simultaneously.

It is your choice to run with a huge cache. In order to ensure that modem users get their work reported on time I have no choice at the moment but to have EDF entered if there is work with a deadline of less than 2 * the queue size as I do not have permission to separate the queue size from the connect interval. PLEASE NOTE THE LAST ITEM.

---

BOINC WIKI

>As it stands, there is a way for those that want to try to micromanage their >BOINC to do

Why is it so bad, when volontairs just want to be able to drive the client as they want to have it? Are we slaves of a (really not opmimal working piece of code) How many more bugs wil be found ?

it's still our cpus(money) which is spend to the project.

Imagine you have a car and you are only allowed to use streets labeled xy.


The problem with so called "developers" is, they can't acccept that somebody could have a different opinion/knowledge/point of view as they have.

It's not possible to have productive talk with them as long the see "no error", just design.

The way how those 4.4x clients are brought to public shoes (to me) that there is much room for improvements/optimisation.


well when software is developed, bugs are part of the story.
It's my very personal point of view, nobody must share it, I find it's a shame when "enduser" as we are, are finding so much "unconfortable situation", not speaking about not working or bugs.

One is for sure, when the NASA would play such a beginners game, they would never been able to lead earth.


As it stands, there is a way for those that want to try to micromanage their >BOINC to do
Yes this will don emore and more.

Don't be surpriced to see one day some tools, able to schedule the schedule
and correct the spoiled values in the clients states.

Situations like this brocken outcomming of those 4.4x clients
and how tey are handeled (are they..) urges people to thing about solution.

Im very sure, the first boinc mods/hacks/tweaks or other boinc client "optimisatior" add ons will come out very soon.

Like it was done for several "other". I like the hacks for my palm or psion they give me as customer more for the money, they are added value.

How many tweak utility are out only for m$?
A lot.

So how many time "mature" and even positive oriented "customer" of boinc will let the clients act no like they desire?

It's so simple if the client is able to get work itself is a good client.

If a client is sooooo buggy and letting dry the client(s) it's a bad client.

It's just easy as that.

Right now I need much more time to handle what I didn't had to handle with 4.19/4.25 clients

The new, still not propper working scheduler policy (it's not a claim, it's a fact) is more frightening people instead of giving them help.


still friendly but underwhelmed

ric

/NNR

---

<img src=\"http://www.setisynergy.com/images/stats/comb-207.jpg\">
multi Project BOINC Stats
<a href=\"http://www.setisynergy.com/stats/teams.php\">Team</a>
<a href=\"http://www.setisynergy.com/stats/individuals.php\">Individual</a>

Here's my guess about what's next:
1) Loose ability to select resource share.

2) Loose ability to pick projects

After that the only decision that we'll have left is:

Crunch or not crunch. "We'll make every other choice for you, You wanna help science don't you?"

I really doubt you'll ever loose the ability to choose what projects you wish to participate in. That would be the death sentence for BOINC.

As far as scheduling goes, once BOINC settled in on my PC, there was little difference in my operation of 4 constant projects and 1 occaisional project. The major change is if I want more work I now have to suspend everything but what I want to work on and it will pull in the full allocation for that project and then I can resume. For the most part I'm finding BOINC keeping enough WU's in place to continue crunching without interuption. I know it varies by how many projects you have, your cache settings, etc but as of this moment, it's meeting most of my needs.

I do agree with you though that user controled features are going by the wayside in favor of full automation. That I don't agree with. I really beleive that as they must cater to both the various projects as well as the two types of users (ones that like to tinker with settings and ones that don't like to tinker with settings), the programmers are stuck between trying to please everyone and that's just impossible.

The developers guess is that those that do not pay attention to their BOINC clients vastly out weighs those that do - therefore as much automation as possible is good.

The case for extra control has to be made well to get past Dr. Anderson. I am trying to get a split between queue size and connect interval.

As it stands, there is a way for those that want to try to micromanage their BOINC to do so (suspend is there, and is not as far as I know going away).

Yes, automatic operation is required for those install and forget types, but I can not agree too this lack of control. I know of few programs today that doesn't offer option for the user to personalize the software operations.
Suspend is negative control. This is not an acceptable reply. What is needed is real possitive control within the GUI.
Since Boinc obviously has no way of acuratly estimating the capabilities of individual systems. A real user controled update is needed. One that actually does get the number of WU to fill the cashe for a project. The BOSS may like the current connnect # , but it is basicaly useless for both Modem or DSL and is a rediculously over simplified approach to controlling DL.
e.g.
Last week BOINC only worked on the 2 project I had WU for and refused to DL unit for my other 2 active project. -- no panic mode-- It ignored my update.
This week a get WU for those 2 project and none for the original two projects. --- I KNOW everything will eventually balance out, but that's not the point. I DON'T have any control over what the software is doing on MY COMPUTER!
I should not have to find tricks and work arounds to get Boinc to do what I want.
All aspect of the operations of BOINC should have user overide, otherwise we are no longer USERS, but just going along for the ride.
The 'Developers' should not be ignoring the people that donate their computer to this project and are willing to expend their time and resource to improving it. I can assure you that this is the fastest way to loose those individuals that are willing to invest of themselve to see Boinc succeed.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

[quoteIf a client is sooooo buggy and letting dry the client(s) it's a bad client.
[/quote]
This is the sole concrete problem that I found in your post. 4.45 will get work from anywhere that is contactable if a CPU runs dry (which IS better than 4.19 was doing - if a CPU ran dry in 4.19 it would not get work from projects that already "had enough work on board").

The rest of the post had no substance that could be worked into anything.

---

BOINC WIKI

[quoteIf a client is sooooo buggy and letting dry the client(s) it's a bad client.

This is the sole concrete problem that I found in your post. 4.45 will get work from anywhere that is contactable if a CPU runs dry (which IS better than 4.19 was doing - if a CPU ran dry in 4.19 it would not get work from projects that already "had enough work on board").

The rest of the post had no substance that could be worked into anything.[/quote]

Ok why should a project get work from a contactable project if it already has enough work from that contactable project and if it has work from a contactable project how can the CPU be dry?? Your statement does not compute!!

---

I'd rather speak my mind because it hurts too much to bite my tongue.

American Spirit BBQ Proudly Serving those that courageously defend freedom.

[quoteIf a client is sooooo buggy and letting dry the client(s) it's a bad client.

This is the sole concrete problem that I found in your post. 4.45 will get work from anywhere that is contactable if a CPU runs dry (which IS better than 4.19 was doing - if a CPU ran dry in 4.19 it would not get work from projects that already "had enough work on board").

The rest of the post had no substance that could be worked into anything.

Ok why should a project get work from a contactable project if it already has enough work from that contactable project and if it has work from a contactable project how can the CPU be dry?? Your statement does not compute!![/quote]
Sure it does. Figure a CPDN WU with 500 hours left and a 50% resource share with S@H. S@H is not providing work, however CPDN has more than 10 days * 0.5 or 5 days of work left. CPDN has "enough work on hand to cover its share". I had this happen repeatedly with 4.19. A CPU on a dual idle, and no way to get work for it. I wrote a CPU idle check into the new scheduler - it unfortunately did not work right the first time. If a CPU is idle, the scheduler should be getting work from anyplace that it can (only limits are suspended by user, no work request by user, or deferred because of communications difficulty or no work available).

---

BOINC WIKI

I have a trio of points to toss in.

i). In any event..... is BOINC ready for mass consumption. If it is ( I think not given the recent scheduler probs) can the masses drive it unless there a good deal of automation. I suspect not tbh. So it may be that its about choices....us advanced drivers should be able to better determine how it runs if you like and the average driver can go auto pilot cos he cannot do it or indeed does not care to do it. So there's a challenge for boinc architects/developers there - competence levels and choices.

ii). My guess, if I were sitting at UCB, is that perhaps the projects should be more controlable. I say this because if seti needed more work done why shouldn't my PC be asked to do more of that instead of say cpdn. The opposite applies also....if Einstein was more needy why not do the same. In other words some lattitude for those who need the results to be able to jointly decide that say, this week....seti needs 10% more throughput. Perhaps cap it at 10% say so we don't lose our input to all this. This is on the basis someone has signed up for the projects concerned of course so 'cos I don't run Einstein then I won't be asked to. But because i run seti and cpdn then they have that 10% sway. That's quite porweful for them I think and good for the science.

iii). I have read some of the development subscriptions. It takes a while to get to grips with what is going on but you do get a drift of where things are going. And you can have your voice there too if you want. LOL I've made a couple of useless suggestions to date hehe. But its good information and some of the points raised in this thread have been discussed there.

That's my three pennies worth.
Ian

---

I have a trio of points to toss in.

i). In any event..... is BOINC ready for mass consumption. If it is ( I think not given the recent scheduler probs) can the masses drive it unless there a good deal of automation. I suspect not tbh. So it may be that its about choices....us advanced drivers should be able to better determine how it runs if you like and the average driver can go auto pilot cos he cannot do it or indeed does not care to do it. So there's a challenge for boinc architects/developers there - competence levels and choices.

This is probably what is keeping Berkeley from shutting down classic.

The automation needs to be as good as possible so that BOINC can just be left alone once it is set up. The tools for micromanagement may be a bit rudimentary for quite a while.

ii). My guess, if I were sitting at UCB, is that perhaps the projects should be more controlable. I say this because if seti needed more work done why shouldn't my PC be asked to do more of that instead of say cpdn. The opposite applies also....if Einstein was more needy why not do the same. In other words some lattitude for those who need the results to be able to jointly decide that say, this week....seti needs 10% more throughput. Perhaps cap it at 10% say so we don't lose our input to all this. This is on the basis someone has signed up for the projects concerned of course so 'cos I don't run Einstein then I won't be asked to. But because i run seti and cpdn then they have that 10% sway. That's quite porweful for them I think and good for the science.

There does not have to be any collusion between the projects to decide who needs the extra power this week (can you immagine the political wrangling going on in that meeting?). If a client asks a project for work, and that project does not have work available, the client will look to a different project for work. The key to determining if a project does not need work done is if it is out of work to do. And it can go way over 10% in any given week.

iii). I have read some of the development subscriptions. It takes a while to get to grips with what is going on but you do get a drift of where things are going. And you can have your voice there too if you want. LOL I've made a couple of useless suggestions to date hehe. But its good information and some of the points raised in this thread have been discussed there.

That's my three pennies worth.
Ian

---

BOINC WIKI