One WU per GPU and you don't get another one until

Last WU is uploaded and credit is granted.

OK with me, but I can (and do) accomplish that now with zero resource share. However, they could grease the wheels a little by providing more granularity in their bonus system. They are probably not prepared to do a full "Quick Return Bonus", which calculates the bonus on a continuous exponential curve, but they could provide more steps. For example, rather than just 24 and 48 hour bonus levels, they could start at 6 hours and have increments every six hours until maybe 36 hours. That would keep an incentive for the slower cards, while rewarding the faster cards appropriately. They can work out the numbers to suit themselves, but the infrastructure seems to be more or less in place for that already.

Besides it makes more "profitable" to have a low cache setting even for fast hosts.
So basically it will encourage everyone to lower their cache size.
I think this is a very good idea.

Before I go to bed.

Betting Slip starts his argument with the wrong hypothesis:

“GPUGRID project needs the fastest turnaround times possible and every second counts!”

This seems to me completely out of place:

First of all if a project needs a turnaround time that fasts, it’s on the wrong place with BOINC as its platform as it is a scientific citizen project depending on volunteers and their willingness to spend quite a lot of their money on hardware and energy. If there is really the need for turnaround times at the speed of light, I think the project shall pay its time on a supercomputer! As GPUGRID decided to use the BOINC platform, I do think the turnaround time is important but not every second counts, as Betting Slip likes to imply.

Second: As Gerard wrote in another post somewhere, there is an intellectual process in analyzing the generated data from the WUs and generating the next batch of WUs, as the scientist has to decide, where to go. So if GPUGRID really would need the results that fast as Betting Slip suggests, GPUGRID staff would have to work 24 hours / 7 days to analyze and generate new work, which it clearly does not, as normally WU shortage occurs over the weekends. And I think as it is a scientific research project publishing papers, it is not in a Formula 1 race, where every second counts!

This said, I think your suggestion of JIT(Just in Time) and all your further argumentation is discriminating all the participants which can not afford or are not willing to buy and/or replace the fastest GPU of every card generation, or with slow internet connections or do run two WUs at a time with no benefits what so ever for the project!

I would like to propose a JIT policy be used on this project and I will attempt to articulate why.

In view of this projects need for a "FAST TURN AROUND" of WU's would a policy of ONE WU per GPU and a GPU only gets another when it has returned the last one. This simple policy would surely speed the throughput of WU's especially since GERARD has expressed on this forum a desire to do that and I would think he considers it an important goal.

This would also end the inefficiency of having a WU cached on one machine for several hours that could be RUNNING on another machine that can't get any work.

We could get a faster throughput of WU's and from that an increasing availability of new WU's because new WU's are generated from returned results.

Does that make sense to you?

This proposition doesn't make much sense to me. If anything, it will only achieve to slow WU processing dramatically!

Requiring a WU just completed, in order to get another one, means hosts that have not just completed a WU (or new hosts getting in the project) will never get a new WU! Unless BOINC supports priority queuing (and the GPUGRID people implement it), this is simply not feasible.

Without priority queuing, and with the current scarceness of WUs, eventually most hosts in the project would be denied new WUs, with the exception of a few lucky / "chosen ones". Not efficient and not fair!

---

One WU per GPU and you don't get another one until

Last WU is uploaded and credit is granted.

OK with me, but I can (and do) accomplish that now with zero resource share. However, they could grease the wheels a little by providing more granularity in their bonus system. They are probably not prepared to do a full "Quick Return Bonus", which calculates the bonus on a continuous exponential curve, but they could provide more steps. For example, rather than just 24 and 48 hour bonus levels, they could start at 6 hours and have increments every six hours until maybe 36 hours. That would keep an incentive for the slower cards, while rewarding the faster cards appropriately. They can work out the numbers to suit themselves, but the infrastructure seems to be more or less in place for that already.

Besides it makes more "profitable" to have a low cache setting even for fast hosts.
So basically it will encourage everyone to lower their cache size.
I think this is a very good idea.

It would also keep people buying the faster and more powerful cards, whereas the 1 unit at a time with the longer time bonuses like they have now means that even if they do run 3 units at a time they can still get all the time bonuses, on top of chewing thru the units very fast.

No your gpu isn't loaded to almost 100% but you are finishing units well within the new time bonus time frames, they will need to be adjusted though as the cards get more powerful and faster. I see a 980 is finishing units in about 4 hours now, so even the 6 hour time frame may not be quick enough, depending on whether it is doing 1, 2 or 3 units at a time to get that time.

I would like to propose a JIT policy be used on this project and I will attempt to articulate why.

In view of this projects need for a "FAST TURN AROUND" of WU's would a policy of ONE WU per GPU and a GPU only gets another when it has returned the last one. This simple policy would surely speed the throughput of WU's especially since GERARD has expressed on this forum a desire to do that and I would think he considers it an important goal.

This would also end the inefficiency of having a WU cached on one machine for several hours that could be RUNNING on another machine that can't get any work.

We could get a faster throughput of WU's and from that an increasing availability of new WU's because new WU's are generated from returned results.

Does that make sense to you?

This proposition doesn't make much sense to me. If anything, it will only achieve to slow WU processing dramatically!

Requiring a WU just completed, in order to get another one, means hosts that have not just completed a WU (or new hosts getting in the project) will never get a new WU! Unless BOINC supports priority queuing (and the GPUGRID people implement it), this is simply not feasible.

Without priority queuing, and with the current scarceness of WUs, eventually most hosts in the project would be denied new WUs, with the exception of a few lucky / "chosen ones". Not efficient and not fair!

The idea is that if someone has a high powered gpu and chooses to run 3 units at a time, they could cache on their system as many as 18 units per day, the rough number they could do if they were finishing them in 4 hours each. BUT if that same person had to finish a unit, get to 99% to start downloading a new unit, then they would only be caching the unit they are working on plus the new units they only get at the very end of the processing time, and there would be more units on GpuGrid for everyone else to download, until the Project runs out.

That person finishing units in 4 hours would still get to do 6 units per day, but if they ALSO adjusted the time bonus credit granting system, then that person could get similar credits to what they are getting now, but still leave plenty of units for everyone else wanting to help too.

The problem with not doing something like this is that they could scare people with lesser capable gpu's away, and then when someone with a very powerful gpu has problems and/or leaves the project, the project has no one to take up the slack and the project suffers. As stated elsewhere the project does not work 24/7/365, but we crunchers do, keeping alot of users happy keeps the project going for a longer time. Specifically catering to the latest and greatest gpu's is all well and good, until the users shut their systems down. Making small changes along the way keeps lots of people happy and the project is sustainable over the long term. The old tortoise and the hare analogy is what I am saying. Have lots of tortoises means it could take forever to reach the goals, having nothing but hares is great, until they leave for someone place else. Having a mixture is better, IMHO. Finding a way to do that that makes sense for both the project and the users is what we are talking about.

Since we are a wonderful community of crunchers, devoted to "The Science", affectionate and considerate to one-another (especially so the mega / divine crunchers towards the mere "mortal" crunchers), why don't we all lower our work buffer to something like 5 minutes (or even zero, why not??), so that the WU pool has as many available as possible?

Why can't those that run > 1 WU on 1 GPU revert back to 1-on-1, at least for the current "dry" period, sacrificing some "efficiency" (or is it "more creditzzz!") for the benefit of better WU distribution?

Why do we need the project to enforce fairness unto us, and not be fair by ourselves??

Maybe RAC is the single most important crunching motive after all...

---

Everyone has his own definition of "fair". If I were to believe some of them (which is unlikely), "fair" means requiring the GPU manufacturers to limit the speed of their cards so that some of the crunchers on GPUGrid don't fall behind in the ratings.

My definition of "useful" is for the science of GPUGrid (and all the other projects) to be advanced as fast as is feasible. I let the scientists figure that out. Sometimes they want the largest number of work units possible but don't care much about the delay ("latency" in computer-ese), and other times they want the delay to be minimized, since that gets back results they need to build new work units based on those results faster. It ultimately is dictated by the science they are trying to do, and our ideas of "fairness" are more or less irrelevant insofar as I am concerned. I will adapt my equipment to their needs, rather than vice-versa, and maybe get some useful work done.

GPUGrid isn't my only project. I'm attached to 59 projects.

I run certain cache/buffer settings that minimize the RPCs to the projects' servers, while also keeping my GPUs satisfied despite the GPU Exclusions I have in place that cause work fetch problems.

And my goal is to maximize GPUGrid's ability to get work done, utilizing my resources. I couldn't care less about the credits. So, generally, to maximize utility, 2-on-a-GPU is the best way to do that.

If a change should be made to increase project utility during times when work units are scarce, it should be made server-side. I recommend my prior proposals.

I did not want to finish my point without some numbers.

But first reading a new the discussion from yesterday and all the answers from today, I would like to stress what a lively community we are! And there seems varying ways to be “fair”, and it seems that I have missed some.

I still would like to mention my own experience:
My GTX 570 and GTX 670 (both cards in the higher faster segments of its generation) are used to crunch one WU at the time: GTX570 needs around 76000 seconds to finish a Gerard (with bonuses 24 hour, 50% bonus RAC 255000) and the GTX 670 finishes in around 61000 seconds.
My GTX 970 loaded with two WUs at a time need for each 76000 seconds, which is in line with my GTX 570.
And at least the GTX 650 TI never meets the 24h deadline, needs around 127000 seconds and its usual RAC is 212000 for each Gerard.
I set a very low cache number for all cards, so I will receive new WUS only if the actual WU is nearly finished, otherwise I will miss the 24 limits more often on all cards as I do have very slow and unreliable internet connection.

The two WUs of the GTX970 are more or less in line with the same card segment on the previous two generations. The GTX650TI never finishes the WUs in 24 hours, and I would like to mention that in the forums you can read that GTX750 TI struggle to comply with the 24 hours limit as well.

Therefore I personally do believe JIT and its variants discussed in this forum are not fair at all, as it obliges to have always the fastest cards of each generation and therefore benefits the users who can afford changing their GPUs each generation and buy the fastest card of each generation.

So as we can see with all the comments, from the user side there should be a much liberty in deciding how to tweak / run the WUs on their computers within the established rules of GPUGRID to comply with the established 24 / 48 hours limits to their liking.

However Betting Slip I am open to any help to tweak my cards to increase the through put, as I am running all the cards out of the package, and do only set the fan speed as high as possible.

Therefore I personally do believe JIT and its variants discussed in this forum are not fair at all, as it obliges to have always the fastest cards of each generation and therefore benefits the users who can afford changing their GPUs each generation and buy the fastest card of each generation.

I certainly do not plan to rush out and buy the fastest card just to maximize my points. If you want to, that is up to you, but no one is obliged to. The point system, in my view, should reflect the value to the project. How the user responds to that, like how he spends his money, is up to him.

Maybe I took it personally, or just my tranquilizer had rolled away?

Since we are a wonderful community of crunchers, devoted to "The Science", affectionate and considerate to one-another (especially so the mega / divine crunchers towards the mere "mortal" crunchers), why don't we all lower our work buffer to something like 5 minutes (or even zero, why not??), so that the WU pool has as many available as possible?

That's a provocative question, but easy to answer:
The group you refer as "we all" does not exist as a single entity, therefore it can't act like a single entity, so must it be "governed" by rules and motives to act coherently and effectively. (e.g. there are many contributors who don't read the forum at all - so they don't know that they should do something.) How many people read this thread at all? It has 448 views so far - that's much less than the active contributors.

Why can't those that run > 1 WU on 1 GPU revert back to 1-on-1, at least for the current "dry" period, sacrificing some "efficiency" (or is it "more creditzzz!") for the benefit of better WU distribution?

My personal reason to have a spare workunit is that I have a strong evidence, that it's in much better hands on my host than on a host which fail every single workunit. You can call it vigilantism, but it is certainly the result of the inadequate governing. (i.e. the server gives work for unreliable hosts)

Why do we need the project to enforce fairness unto us, and not be fair by ourselves??

The whole time of our civilization's existence wasn't enough to answer this question.
The best answer so far: that's human nature.
The first part of my reply is also applies here.

Maybe RAC is the single most important crunching motive after all...

Here we go again. Every time it comes to "reform" the credit system this assumption/accusation/disillusion is made.
Maybe we'll have a cure for those deadly illnesses in 10-15-20 years from now, and maybe this project will have a tiny part in it, but it is certainly not enough to convince the rest of the population to take part in it. I am confident of that we could have that cure right now, if all people of the wealthier part of the world would have been united 20 years ago for this goal, and would have been using their computers since then to take part in biomedical research, but they were playing 3D games, buying new cars & bigger houses instead. Why? Because they are motivated to do so, they are socialized to do so. The credit system is the only thing which could be the "interface" between the "material world" and the "BOINC world". Surely greed and vanity also came along from the real world, but that's human nature (that phrase again). By reforming the credit system we're trying to make the best out of it.

The group you refer as "we all" does not exist as a single entity, therefore it can't act like a single entity, so must it be "governed" by rules and motives to act coherently and effectively. (e.g. there are many contributors who don't read the forum at all - so they don't know that they should do something.) How many people read this thread at all? It has 448 views so far - that's much less than the active contributors.

So, you're admitting that you're not willing to lower your work buffer voluntarily, and the only way for this to happen is for the project to enforce this on us.

My personal reason to have a spare workunit is that I have a strong evidence, that it's in much better hands on my host than on a host which fail every single workunit. You can call it vigilantism, but it is certainly the result of the inadequate governing. (i.e. the server gives work for unreliable hosts)

That's a very selfish argument, which is also not valid: how do you know the results you return are not invalid, every single one of them? GPUGRID has a quorum of one, which makes all returned results potentially invalid! Just because a task doesn't crash on you, doesn't mean it doesn't contain computation errors, especially when running on a GPU. Incidentally, I strongly believe GPUGRID should establish a quorum of two.

Here we go again. Every time it comes to "reform" the credit system this assumption/accusation/disillusion is made.
Maybe we'll have a cure for those deadly illnesses in 10-15-20 years from now, and maybe this project will have a tiny part in it, but it is certainly not enough to convince the rest of the population to take part in it. I am confident of that we could have that cure right now, if all people of the wealthier part of the world would have been united 20 years ago for this goal, and would have been using their computers since then to take part in biomedical research, but they were playing 3D games, buying new cars & bigger houses instead. Why? Because they are motivated to do so, they are socialized to do so. The credit system is the only thing which could be the "interface" between the "material world" and the "BOINC world". Surely greed and vanity also came along from the real world, but that's human nature (that phrase again). By reforming the credit system we're trying to make the best out of it.

I'm with you 100%, I love credits myself! But, I hate hypocrisy! We're all here "for the science", but will complain in no time when the queues run empty!! We're not only eager to help the project, we demand to "help" (makes me wonder, how many times we've processed the same WUs, over and over, just so BOINC credit is generated and awarded...). We don't like it when scientists issue very long WUs and we lose the 24h bonus! On the other hand, we're sympathetic to the complainers, but we rush to grab as many WUs as we can, so our RAC isn't affected by the drought...

Long story short: People, you're voluntarily participating in BOINC and GPUGRID to help! The queues running empty should make you happy, because processing supply is far exceeding the demand! The project is making progress and the scientists get their results back ASAP. Realize what you're doing here, setup back-up projects and stop whining!! Also, it won't actually hurt you if you lower your work buffer and let some other folk process a WU, get some GPUGRID credit and maybe a GPUGRID badge. Your GPU may get a WU from a "humbler" project and you may lose your RAC first place, so what??

---

So, you're admitting that you're not willing to lower your work buffer voluntarily, and the only way for this to happen is for the project to enforce this on us.

I admit that.
Do you admit that if me, you and the 20 other people who actually read this thread would do lower their work buffer it still wouldn't help to solve the shortage because the other 3000 users just didn't care at all? BOINC is supposed to be a "set & forget" system, so it has to be well configured to work optimally without user intervention.

That's a very selfish argument, which is also not valid: how do you know the results you return are not invalid, every single one of them?

I don't know, just as you don't know either. No one does, so we all are similar from this point of view, which invalidates your argument.
But I got the goal of your argument, therefore I admit that I'm selfish. I also think that I'm not the only one here. Moreover we don't have the time and resources to convince the other 3000 careless / selfish participants to be careful & fair. It's much easier to create a system which enforces on us what is best for the system. That's how almost every community works.

GPUGRID has a quorum of one, which makes all returned results potentially invalid! Just because a task doesn't crash on you, doesn't mean it doesn't contain computation errors, especially when running on a GPU. Incidentally, I strongly believe GPUGRID should establish a quorum of two.

There's a lot of random factors involved in the simulation, so it will always have two different outputs when the same workunit is run twice.
This would take a major rewrite of the application, also it would cut the throughput in half.
I think the scientists filter the wrong results through visual checking.

But, I hate hypocrisy! We're not only eager to help the project, we demand to "help" (makes me wonder, how many times we've processed the same WUs, over and over, just so BOINC credit is generated and awarded...).

By asking for quorum of 2 you've asked for the same thing.

We don't like it when scientists issue very long WUs and we lose the 24h bonus! On the other hand, we're sympathetic to the complainers, but we rush to grab as many WUs as we can, so our RAC isn't affected by the drought...

I'm concerned about my falling RAC is mostly because at first sight I can't tell the reason of it, which could be that my hosts failing tasks, or there's a shortage, or there's an internet outage. Any of them is annoying, but only the shortage could be prevented.

Donating the computer time, pay the electrical bill associated with it, and buying computer parts I otherwise would not need, is the philanthropic part of the equation participating in BOINC projects.

But reading and participating in the forums as well as the RACs are the fun it involves participating, and yes the later motivated me to buy some new stuff to get over a million RACs a day.

I still do not see any benefits in JIT, other that finally we are all at each other throat, discussing our personal motivation for participating!

Let’s get the job done, crunching through all the WUs as fast as possible!

... finally we are all at each other throat, discussing our personal motivation for participating!

Let’s get the job done, crunching through all the WUs as fast as possible!

Suddenly I've realized that we're doing a Mark Twain adaptation here in this thread. :) Tom Sawyer Whitewashing the Fence

Suddenly I've realized that we're doing a Mark Twain adaptation here in this thread. :)

http://www.filefactory.com/preview/4o1qp2s3vet9/

Oh, dear, this is all doubledutch to me :(. I process about four GPUGrid WUs every weekend if available. If there's no work, I process other WUs.

You raise a good point; the only reason we are having this discussion is that there has been a shortage of work. That may be easing, but the point still remains: how to prioritize the distribution of what they do have (if at all). Only GPUGrid can really decide that, since they know best what they are trying to accomplish. I hope they consider the ideas here though, and set the proper rewards. I think the crunching will fall into line after that.

You raise a good point; the only reason we are having this discussion is that there has been a shortage of work. That may be easing, but the point still remains: how to prioritize the distribution of what they do have (if at all). Only GPUGrid can really decide that, since they know best what they are trying to accomplish. I hope they consider the ideas here though, and set the proper rewards. I think the crunching will fall into line after that.

I agree there is little point of continuing this thread and it's time for GERARD or GDF to get involved and let us know what would be good for them and the project.

Hello, hello

I don't personally see any point to enforce a maximum amount of 1 WU per user. I think this is a decision that must come from the user, for the various reasons that you have expressed in this thread.