The points are based on the work done, not the amount of time, if you do 100 points worth in 4 hours and your wing man does 100 points in 8 hours, you are getting 2 times the points per hour of your wing man.

besides 5,000,000 points is still not enough to buy a cup of coffee ;)

Crunch on

If it took the wingWU twice the time than my WU did for the same work, then it is imbalanced that my WU gets the same points as the wingWU. If the amount of workload is the same, the machine that turned in faster actually did more work (and/or was more efficient, effective) to bring the same work faster. Please differentiate work between "work-to-be-done" on one hand, and on the other hand "work-to-be-supplied". What is the same is the work-to-be-done. The work-to-be-supplied is the one that varies. If the same work is done faster, there should be a difference in credits, otherwise, there is no incentive for medium-to-high performance machines. By the way, the formula for work is shown as a function of time; any quantification of work (and with it the points) needs to take time into account.

If the argument is that the points from my WUs being paired to slow wingMachines is the same as the points from my WUs being paired to fast wingMachines, then why not pair my machines to fast wingMachines, and see how that one goes?
;

Hello anhhai

Reference: anhhai [Jul 9, 2011 8:57:28 PM] post

Greetings.

Thanks for your response.

The idea is that for any given amount of work-to-be-done, an output resulting from the work-supplied and done faster has more value than the same output done longer. For example, for the same 1,000,000 calculations in a WU, the machine that produced the result earlier should get a higher points than the machine that produced the same result slower. The involved machines should not get the same, say, 100 points.

To test the idea, lets try to stress the limits. Given a crunched WU, would it benefit WCG if the WU was done after, say, 1-year, and returned the following year? Would it benefit WCG if the same WU was done after, say, 1-second, and returned to WCG the next second? The cruncherMachines involved may be doing the same work alright, but if the time factor is taken into account, clearly there is more value from doing the same work faster -- which value should be reflected in the form of a higher points -- in addition to the time advantage that the faster cruncher gets -- to crunch even more WUs and get even more points. If ever there is apprehension that the fasterMachine will have its advantage snowball, well, that is how things truly are -- much like what started as a millisecond-lead in the first lap of a race may well end for the racer getting a full second lead going in to the final lap. To not provide an incentive for doing a given work faster is akin to not motivating the racer to turn in faster lap times.

I wanted to focus not so much on the right or wrong side of the valuation model (as what is involved in the word "fair" or "unfair"), but more on the material aspect of being, well, not balanced. There is imbalance because for the same work-to-be-done, the fasterMachines bring more value to the same output (by producing the same work faster) compared to slowerMachines, but for which more value the fasterMachines do not get added credit.
;

Distributed Computing exists for the very reason that there is no rush in getting the individual data blobs back, so generally WCG allows 10 days. It's 7 days for HCC, which is driven by keeping the storage use down and when WCG can they will clear completed batches ASAP to keep the scheduler in particular leanest and meanest.

Some projects give a bonus for < 24 hours return for a reason, some require faster turnaround because the next calculation depends on the previous. Soon there's server code that can tell the client that has a specific data blob to send the result back immediately upon completion [think some GPUgrid project requires that, else the progress just bogs down]. That function is good in that WCG could then rely much more on a swifter Beta quorum matching and reducing the need on the side of the client owner to micro-manage. The price is increased scheduler hits, so it will be sparsely used.

--//--

And there's the nub of the problem.

andzgrid wants more points for the faster processor for returning results more quickly.

TylerChris wants more points for the slower processor to even up the points-per-run-hour statistic.

Now I have a headache. Please, guys - don't force me to have sympathy for the politicians whose job it is to minimise the noise from the squeaky wheels - the chorus of a thousand and one ways to scream "It's not fair!"