Would it be possible to modify the BOINC client to look at the entire cache of workunits as a single pool, and assign work to whatever resource needs it at the moment it's ready to be worked on?

How do you force this updated client onto everyone out there? A couple of people here don't want to update to anything beyond what they have because they don't like the new smell of the new BOINC, and they are actively looking at it every day. I understand that the biggest problem is that there's set-it-and-totally-forget-you-ever-installed-anything-clients out there that do this all by themselves? So, how do you update those? Or should they just be blocked?

---

So what is the way forward.

I'm inclined to think that setting limits on a per-host basis would be more sensible. The current fixed limits of 100 CPU + 100 GPU penalize the most productive crunchers while providing incentive for others to circumvent the system.

Each host's total allocation wouldn't necessarily have to be identical. It should probably be based on number of cores and GPUs, or perhaps using an algorithm like the APR calculation. In any event, for a given host, rescheduling from one processing method to another would have no impact to a host's total allocation.

Don´t belive it´s to hard to implement, since the servers actualy knows how many WU each hosts have pending, then block cheating it´s simple.

Think, the @¨&@%!!! limits uses almost the same function, so you just need to block the DL of new WU form a host who allready exceded the 200WU limit in their pending cache. Some tweeks could be needed to handle the crashed hosts, etc. but in the deep it´s a very simple function.

Right, I'll craft a lengthy post detailing the way I see the whole situation. It'll take a while to present the things needed in a diplomatic, non-inflammatory way, but I think it'll help at this point, and explain why I've stayed out of this particular circus (until now)

The way I see it, we have a pretty clear black-hat versus white hat situation.

When you build a system, if it's needlessly complex and full of holes (exploits), then they'll be exploited. Is that good, bad, or just a fact of life ?

With permission of a mod (William) here's a one off youtube link to illustrate the point. http://www.youtube.com/watch?v=onR7PD3Grc0

In the real world, there is no black and white, i.e. no clear line. Nonetheless we have the developers removed from the situation, focussed on project-centric issues, while it's the users than don the black or white hats with respect to defending the user experience. I'd point out the the white hats are few, disunited, with very little time, money and other resources to continually patch exploits. The black hats are legion, mostly anonymous, and always looking for some holes. If there are limits in place deemed too tight, they will push for weak points.

Most (not all) of us would agree that the user experience is in a pretty shocking state at the moment, and it's easy point the finger at the black hats when the reality is more insidious. It turns out, when you dig deeper, that a lot of these complex issues are connected, and would be avoided by simpler operation with best practices, and development channels that were more open.

These interconnected systems include the CN and estimate mechanisms, and there are known exploits that apparently have yet to be found by the black-hats. It's in that respect that some of us are liaising with David to establish avenues to get these fixed before they proliferate.

Make things simpler, solid, lift limits, use best practices, and most of the problems go away. Nobody said it's easy to do that. It's easier to just keep applying bandaids and tighter limits when a particular design needs to be reefed out, simplified, stabilised and generalised.

The way forward isn't clear yet, but what is clear is that the user experience has few promoters, and that's something we all need to work on.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

Would it be possible to modify the BOINC client to look at the entire cache of workunits as a single pool, and assign work to whatever resource needs it at the moment it's ready to be worked on?

How do you force this updated client onto everyone out there? A couple of people here don't want to update to anything beyond what they have because they don't like the new smell of the new BOINC, and they are actively looking at it every day. I understand that the biggest problem is that there's set-it-and-totally-forget-you-ever-installed-anything-clients out there that do this all by themselves? So, how do you update those? Or should they just be blocked?

No force needs to be involved. For those that believe this is a problem, they can choose to upgrade. Those that choose not to upgrade will still suffer from the same issues and will need to further babysit their machines and continue to reschedule.

For those that set and forget, well, they're already not upgrading and not complaining, so this isn't an issue for them.

Well said, Jason. That is the angle I'm trying to view this whole thing from; what needs to happen at a systemic level that will alleviate the need to do things that are currently frowned upon in a way that won't be harmful to the goals of the software?

Of course there's no easy way forward. Sometimes I really wish I could help the developers out more, but I just don't have the time these days.

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

This thread isn't really about the credit system though. Fixing the credit system is actually a different discussion altogether.

The current issue at hand is the limits put in place by the project to prevent their various subsystems from being brought to their knees, and whether it's morally right to reschedule your own tasks to more efficient resources on your system, and what effect it has on other people's credit when you do so.

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

This thread isn't really about the credit system though. Fixing the credit system is actually a different discussion altogether.

The current issue at hand is the limits put in place by the project to prevent their various subsystems from being brought to their knees, and whether it's morally right to reschedule your own tasks to more efficient resources on your system, and what effect it has on other people's credit when you do so.

But if I'm not mistaken, then the reason for some people rescheduling is the flawed credit system.

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

The 100 task per GPU limit isn't anything to do with the Credit system, it is to do with the hosts that were carrying 10,000+ tasks,
every time they reported, Boinc had to tell the server which of those 10,000+ tasks were present on the host, with the Hurricane link being overwhelmed with downloads, those reports were timing out,
the long term goal I believe is for Setiathome to have longer tasks so hosts need to carry fewer tasks and so lessen the database load.

Claggy

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

This thread isn't really about the credit system though. Fixing the credit system is actually a different discussion altogether.

The current issue at hand is the limits put in place by the project to prevent their various subsystems from being brought to their knees, and whether it's morally right to reschedule your own tasks to more efficient resources on your system, and what effect it has on other people's credit when you do so.

But if I'm not mistaken, then the reason for some people rescheduling is the flawed credit system.

And that takes us back to the individual versus the collective.

What do you do with a flawed credit system - subvert it, or fix it?

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

This thread isn't really about the credit system though. Fixing the credit system is actually a different discussion altogether.

The current issue at hand is the limits put in place by the project to prevent their various subsystems from being brought to their knees, and whether it's morally right to reschedule your own tasks to more efficient resources on your system, and what effect it has on other people's credit when you do so.

Actually it's mostly about people sucking up tasks well above the limits set which we have mentioned numerous times now over past several months.

And yes, fixing the credit system would go a very long way to stop this practice.

Also no one took much notice about this problem until a certain "Volunteer developer" got caught out doing the same thing.

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

This thread isn't really about the credit system though. Fixing the credit system is actually a different discussion altogether.

The current issue at hand is the limits put in place by the project to prevent their various subsystems from being brought to their knees, and whether it's morally right to reschedule your own tasks to more efficient resources on your system, and what effect it has on other people's credit when you do so.

But if I'm not mistaken, then the reason for some people rescheduling is the flawed credit system.

Correct, to a point. There are legitimate reasons to reschedule, so it isn't black and white. What we're dealing with here are many interconnected issues (including credit), a lot of which boil down to design issues (as opposed to implementation code). It's the user-centric view that exposes all the weaknesses in the system (people), design and implementation code.

Less bandaid code patches (which inevitably have holes), more design refinement (simplification, stabilisation) to cope with real world operation, and more involvement from developers would be good.

At this point I could explain how I think Boinc development ended up in the hands of two men and a dog, but I won't. Code Patches won't fix those problems. They are systemic, and woefully non-user centric, which is something I hope to find ways to help correct.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Since I got my 2x GTX770 I've discovered what I really knew already; how short 100 APs last, even if it was 100 per GPU it wouldn't make that much difference.

So please fix the damn credit system ASAP :)

This thread isn't really about the credit system though. Fixing the credit system is actually a different discussion altogether.

The current issue at hand is the limits put in place by the project to prevent their various subsystems from being brought to their knees, and whether it's morally right to reschedule your own tasks to more efficient resources on your system, and what effect it has on other people's credit when you do so.

But if I'm not mistaken, then the reason for some people rescheduling is the flawed credit system.

That might be the reason for some people, but I understood that this discussion was supposed to be about those that wish to keep their resources busy and aren't rescheduling for the credits, and the morality of rescheduling for that purpose.

I'll add my point of view before this thread is locked because too many posts are ignoring the rule regarding the c-word given in the original post.

1. The demand for Astropulse work exceeds the supply. Special configurations which allow getting more than a fair share are selfish.

2. The project has set limits which keep the overall average turnaround time short enough that the number of "in progress" tasks don't overload the database. Unfortunately all of BOINC's limit options are in terms of number of tasks, so the limits unfairly apply only to the most capable systems (a "top 1%" gold badge is hardly sufficient compensation). A new limit method which would allow the project to specify *hours* of "in progress" tasks would be better. For instance, if the project could restrict work delivery to 30 hours per CPU and GPU the turnaround would be similar to the present limits but nobody would be running out of work during an outage of less than a full day. Implementing that kind of limits would not be simple, though.

                                                                   Joe

I'm afraid when the masks are removed all the complaining is merely about credits. Note how when my Mac burns through 400 APs in four days it's apparently fine when those 400 are split into two groups of 200. However, if it tries to complete 400 in one batch it's somehow considered 'cheating'. So, what's the difference between running 400 in one batch or 400 in two batches? The RAC is split between two hosts instead of showing up on a single host. Hence, one is left concluding all the complaining is merely about credits.

It's a bad day for science when production is hampered due to people worrying about credits.

That might be the reason for some people, but I understood that this discussion was supposed to be about those that wish to keep their resources busy and aren't rescheduling for the credits, and the morality of rescheduling for that purpose.

Thake a look at my first post on this thread (actualy the 2 post on the thread), if you make part of the 1 or 2 group who need to resheduling to keep your host working you are moraly right and is good for the project, but only if you don´t cheat the 200WU limit.

What we are against are those who cheat the limits in any way, for any reason not just for credits, that´s moraly wrong. We could tell those who cheat for 300 WU are less moraly wrong than those who cheat for 600WU but they are wrong anyway. If the limits exist we all need to respect for the good of the project.

What we need to find is a way to avoid the possibility to that happening, or until then try to make the bad reshedulers stop with that bad practice, not the good ones.

---

Thake a look at my first post on this thread (actualy the 2 post on the thread), if you make part of the 1 or 2 group who need to resheduling to keep your host working you are moraly right and is good for the project, but only if you don´t cheat the 200WU limit.

What we are against are those who cheat the limits in any way, for any reason not just for credits, that´s moraly wrong. We could tell those who cheat for 300 WU are less moraly wrong than those who cheat for 600WU but they are wrong anyway. If the limits exist we all need to respect for the good of the project.

What we need to find is a way to avoid the possibility to that happening, or until then try to make the bad reshedulers stop with that bad practice, not the good ones.
+1

Morals, ethics, respect.

I'll add my point of view before this thread is locked because too many posts are ignoring the rule regarding the c-word given in the original post.

Are you sure that the "c-word" is "credit" and not cheat, cheaters, criminals?
If so then better clarification is needed in the 1st post about what the "c-word" actually is. ;-)

the long term goal I believe is for Setiathome to have longer tasks so hosts need to carry fewer tasks and so lessen the database load.

Claggy

And, unfortunately, current development direction is to debug Android app in slow pace instead of 2x2 or GBT task format promotion.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

As was described here http://setiathome.berkeley.edu/forum_thread.php?id=74125&postid=1478778 limits are needed.
Where to draw the line (threshold value) is not obvious, project -wide (as was stated here: http://setiathome.berkeley.edu/forum_thread.php?id=74125&postid=1479078.

Rescheduling has same relation with credit maximizing as optimized applications usage. Why optimized application usage can't be called "cheating" by some ?

Servers give slower app to everyone. But some (!) install optimized application instead! (why? surely to increase their credits. It's surely the only reason to install opt apps). Are they thinking they better than the others? Why they refuse to use stock app that supplied to everyone? If such slow stock app distributed, then "powers" of this project want that participants use exactly that slow app, instead they would distribute another one. And so on.

Nonsense? Sure. But this just exactly same nonsense that some try to make with rescheduling.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.