Bigadv points change

[bruce]

The "older" SMP cores (e.g. -A3) required 2 or more processors up to (unlimited??). Now that core_a4 and _a6 are being developed, any project that's aimed at the low end SMP folks (e.g. maybe in the smp 2 or 3 or 4 range) can now be distributed to uniprocessor machines, too. Does that make the work of the core_a3 assignments less valuable? Not at all. It actually shows that there's still value in getting some help from folks with a uniprocessor class machine. The QRB will be applied so that the current SMP machines get pretty much what they're getting now and the slow uniprocessor get pretty much what they're getting now and a fast uniprocessor gets something in between, based on both quantity of work and speed of work.

[7im]

@7im because you need to see the whole picture before making an adjustment? Wait untill qrb is applied to gpu and let's see how things look then.

Also, I want to concentrate on bigadv as it's a special case. I don't expect you will ever see it happen on the gpu side for instance.

I don't have to wait to see the picture with GPUs and QRB. That changes NOTHING in regards to the SMP and the -bigadv points curve in question. GPUs will get their own curve. Neither will be related. Not the same client, not the same hardware type, not the same work units, nothing is the same. The QRB for GPUs will be a completely new fabrication.

So as you said, let's concentrate on -bigadv. And as I have said twice before, leave GPU clients out of the discussion.

[mdk777]

So as you said, let's concentrate on -bigadv. And as I have said twice before, leave GPU clients out of the discussion.

Wait, should we try to fix one class, or all the classes of clients?

If you are suggesting a change, as you seem to be doing, why only go half way? Why only a bandaid? A benchmark computer change only delays the inevitable. Why not fix the whole problem?

The whole problem is different points for different classes of clients.

Everyone folding on -bigadv is happy, its the other classes that are the problem.

I don't see how you can parse the problem, they are all interconnected.

[7im]

Not interconnected much at all. GPUs are by nature a different class of machine. The QRB will be different as well. And I'm hoping PG does a better job of fabricating the QRB for GPUs this 2nd time around.

2 pages ago I listed my suggestions for fixing the WHOLE system, which included QRB for all clients. Surely you are not that forgetful. And surely you are not just trying to get a rise out of me, because that would be trolling. So what purpose does your post have besides injecting yourself in an answer I was giving to MTM (hence my quote of his question)?

Let's fix it all. But lets fix the QRB currently in operation, so the next one operates better as well. The next one can be modeled after this one we fix.

[mdk777]

So what purpose does your post have besides injecting yourself in an answer I was giving to MTM (hence my quote of his question)?

Obviously I was agreeing that adding QRB to GPU and Uni processor clients would help balance the perceived point inequity.

I also agree that your most recent post would seem to contradict your previous statements.

Let's fix it all.

Here we agree.

I don't think you fix the whole by attacking one part. A unified point system needs to be established. Robbing Peter to pay Paul will never make anyone happy.

[7im]

Again, you assume things all backwards.

I'm not attacking one part. I'm suggesting we fix the one part that is up and running, but still not working as well as it should, WHILE we wait for the other parts to get going. These are some subtleties you seem to keep missing.

And no amount of points giving to CPU or GPUs will fix the extreme exponential nature of the bonus curve for -bigadv as systems get many multiples faster than the benchmark.

And it's not stealing from anyone. It's correcting a trial program, as one expects a trial program to be corrected. Consider it an unintended bonus for helping to get the QRB system off the ground. Now it's time for a course correction.

Points should not be tripling with each speed doubling, ad infinitum.

[MtM]

Tell me again why we shouldn't have the benchmark machine changed for bigadv?

[7im]

I can not tell you that again because I have not told you that a first time. Just the opposite in fact. But again, it's only a bandaid.

See bandaid reference a few posts back.

[Amaruk]

Tell me again why we shouldn't have the benchmark machine changed for bigadv?

The same machine is used for all CPU clients.

Changing it to a newer (faster) one will simply reduce PPD for ALL of the CPU clients, not just -bigadv.

[MtM]

Tell me again why we shouldn't have the benchmark machine changed for bigadv?

The same machine is used for all CPU clients.

Changing it to a newer (faster) one will simply reduce PPD for ALL of the CPU clients, not just -bigadv.

Why didn't you include the following consideration: bigadv needs not to keep being benched at the same machine's as the other cpu clients are benched on.

What happens if you take bigadv and change it to a whole new client type beyond smp. What if PG then comes and gives us a formula which give us a tie between science and time, saying it's as close as it gets. Would we still argue -bigadv needs to benched on the same machine's as the other clients would run on even if -bigadv would have it's own much higher requirements?

That is the essence of the problem, not the formula used to attribute a value to time needing a change.

I don't see -bigadv as a normal continuation of our previous work, sure it builds on it but it's another exponential increase in possibilities for running computationally heavier work units, and if you enforce a minimum speed limit it can even act as fast lane for a limited number of projects compared to the much much wider f@h high way which is limited still by the slowest contributors in each chain of work units.

So, start to assign more smartly, it's not a new request or suggestion is it? Why not start here when it would match exactly a situation in need of such a fix. It will justify the qualification of speed being important twice: by confirming the exponential slope with the ability to lower ppd for specific project types by changing the benchmark machine which is supposed to be representative of the average system a donor is participating with, and by assuring everyone our q6600's are still fast enough to help with allot of things, but it might be more efficient for science to not have them slow down the other trajectories?

I'm not saying much if anything which has never been said before, am I the only one who would consider applying it now and here? Before taking the quick and easy way out, which I think is changing the qrb formula, a quick and easy way which will bite itself in the behind later on I'm afraid.

@7im I would wish you stopped editing posts after replies been made or add a notion what you changed. I don't understand the reason for it as from the start of our personal messages I said we need to change bigadv, fix the problem where it originates.

[Amaruk]

Why didn't you include the following consideration: bigadv needs not to keep being benched at the same machine's as the other cpu clients are benched on.

Our philosophy is pretty simple: we would like to standardize benchmarks to a single machine and standardize and simplify the bonus schemes now employed.

SOURCE

Using different Benchmark machines is certainly possible, but it will not change the performance curve of any client relative to the hardware it's run on.

[MtM]

7im, why is changing the benchmark machine for bigadv, splitting it of from the other cpu clients, a bandaid compared to changing the qrb formula?

You been saying you want the benchmarking method changed, isn't this the moment to do it? Take the opportunity to benchmark wu's on reference machines representing the average system for a certain project, or tell me any reason why we should not do this? If points seem out of line, it's not because the formula is flawed, it's because of the problem with benchmarking all work units on the same machine, solve it first with benchmarking on the right hardware specific for how the project is configured.

As I said before, I'm also not against going to the second root instead of the third if it's really needed to mess with the formula now to assure we don't loose to many people due to being unhappy or just unsure but I do feel it's not the best way to approach this. I even think it can raise uncertainty in the future, as people will not invest in the latest and greatest as quickly as there is a chance the system will get changed to lower their ROI. And no one has come up with a scientific explanation of why the current 3rd root formula isn't correct anyway, you can't use bigadv as argument. We already established bigadv needs a change in benchmarking machine, that disqualifies it from being a reason to change the formula.

@Amaruk: exactly the point, keep the curve but move it left or right with the benchmark machine along with being able to adjust base points and know for sure how projects will run if you restrict projects to certain hardware requirements.

I never said I was proposing something in line with the current considerations, I don't think that method will work with the project getting spread out over such a broad performance scale. It worked in the past when the highest system running fah was the occasional 2p server at work not being used compared to the normal single or dual core systems people had at home, but it doesn't work anymore with current top hardware compared to the average hardware.

[7im]

...

What happens if you take bigadv and change it to a whole new client type beyond smp. What if PG then comes and gives us a formula which give us a tie between science and time, saying it's as close as it gets. Would we still argue -bigadv needs to benched on the same machine's as the other clients would run on even if -bigadv would have it's own much higher requirements?

That is the essence of the problem, not the formula used to attribute a value to time needing a change.

Yes, this is the essense of the problem. NO, the formula is ALSO a problem. You have posted nothing to show the forumula is accurate for more than 8 cores. You cannot make this claim.

We need to fix both. So answer this question...


On the newest -bigadv-12 work units, a well known individual is is netting 850,000 PPD on a 48 core system.

Is 1 computer with 48 cores, that completes only 1 work unit each day REALLY worth more than 140 (benchmark)* computers, with a total of 560 cores, that completes an average of 70 work units a day? Really?

Then explain it to me! To ALL of us!!!

Our Core i5 benchmark machine gets 6189 PPD

*http://folding.stanford.edu/English/FAQ-PointsNew

[Punchy]

A quick fix to the bigadv-12 6903 work units would be to drop the final deadline down to a more reasonable time (with a corresponding change to the preferred deadline as well). Since they seem to take roughly 2x the older A5 units, 12 days would be more reasonable than 17. That one change would drop the section of the bonus curve in use down to a much less steep part.

I'm curious as to what 12-core machine would take 10.2 or even 17 days to complete a 6903. Perhaps a more careful setting of the deadlines would provide the necessary damping to stop the complaints that started this thread.

[MtM]

I can't with the current system and you know it. I can't argue for keeping it to one benchmark machine so I can't argue against you claiming it is not fair.

The difference is you want to change the formula where I think it's better to shift the curve with adding a benchmark machine better representing the hardware running the actual work units. That implies allot more work I admit as I think you would need to enforce the assignments if you add benchmark machines and match projects to their benchmark profile. That gives more work to the development team which is already working hard on V7. So maybe you're not considering it because it's not feasible to do it right now, I'm not sure. I always seen you as the person who would support adding benchmark 'profiles' in one way or another.

I still think it's a band aid fix to mess with the qrb formula right now. But if it's the only possible option which will keep everyone happy I will concede on that notion as I don't want to keep my foot stiff if it would prevent the most effective means of solving any urgent issue.