Replying to only a portion of post by Keith (SwissNic):

I guess that's a definition thing. I was led to believe the FLOP measurement was the same as defined by the CPU manufacturers. If that's so there's a wide difference in how many FLOPS your CPU does by machine cycle between model, make and series. It's also complicated by those extended instructions (MMX,SSE2)that can process bunches of them quickly. So maybe someone can clarify for both us? It would save me getting the wrong picture. Does anyone know if the Seti/Boinc FLOP is a synthetic thing or related to machine code concepts?

The term FLOPS is only really defined in terms of the particular benchmark which attempted to measure floating point performance.

What setiathome_enhanced is doing is counting floating point operations. If the standard application has a routine which loops i times and contains x floating point additions, y floating point multiplies, and z floating point exponentiations, the FLOP_counter value could be incremented by i * (x + y + z) at the exit from the routine. When someone builds an optimized application, that increment should not be changed even if the mix of operations is actually different. The count is to be treated as an estimation of useful work done so that all applications successfully doing the same WU can be granted the same credit.

Here's an actual formula used for the main count in Triplet finding:

analysis_state.FLOP_counter+=(10.0*numBinsAboveThreshold*numBinsAboveThreshold);

                                                            Joe

Hi Keith,

First let me say that I've dabbled a little in programming but I'm *not* nor do I claim to be a programmer, but I know enough about it to be able to explain what is going on here.

As far as the fpop measurements go, if the application actually counted every operation done on all cpu's and operating systems, you would be getting very little actual work done besides counting and recording fpops. So instead, the application assogms am estimated amount of fpops to each subroutine, and each time the subroutine is called, that number is added to the fpops total that is reported. This is why you don't see any variation in the amount of actual fpops reported. Each work unit has specific needs in crunching and unless there's a problem with a computer handling a particular wu, then the same routines are called the same number of times to crunch that particular work unit.

Overall, the credits reported per hour for any work unit are roughly the same, with some specific exceptions. Pappa has a plot of credits per hour by angle range, and if you were to look at it, you would see that the idea of *all* VLAR wu's are bad and do not give credits at the proper rate is patently false. As a general rule, all angle ranges below the very high ar's give credits at nearly the same rate *with a few exceptions*. There *are* "specific" angle ranges which give lower credits per hour, *and* there are certain specific ar's that give above normal credits/hr. However I don't hear anyone griping about those!!!

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

But it IS all fair.
And for crying outloud, no matter what method is used to calculate credits, a fast computer will always make more credits than a slow one.
I don't thing it's so hard to understand, but oh well, I remember now, I must be a complete moron. ;)


Peace.

Not to put to fine a point on it, I'm getting the feeling you don't actually give a jot about credits. If so, why comment at all ? Surely it'd be something you'd just ignore?

It seems intuitively obvious that we have at least two or three different meanings for the word "fair"

When I read "fair" I think "equitable" -- that everyone has an equal chance of getting "easy" and "hard" work units, and that everyone who does a work unit gets the same credit.

Clearly, some read "fair" and see "equal" -- that an hour of crunching will return the same number of credits no matter how many "easy FLOPs" and "hard FLOPs" are involved.

Some read "fair" as "no less than I used to get when I ran an optimized app."

... and as a result, we're often talking past each other when we start saying "fair."

I think "equitable" is the best meaning....

Hi Ned!

I never thought I'd get a reply fron such a demonstrably balanced individual!
Cool! oops showing my age there ;-)

Equitable is a great term. Yeh I can try and work using that as the word but being realistic, my interpretation of fair, equal or equitable will suffer the same problem. It will be different for everyone else's. Maybe it's not a dictionary issue?

Somewhere, somehow there's got to be a base agreement that most,if not all, can live with without constantly hassling each other. I guess it's silver lining (possibly a needle in a haystack or holy grail!) but it's worth trying to find a bit of common ground to alleviate the simple stress points...

Gonna have to sign off soon, my new 'evaluation' toy is running out of juice ;-)

Nice to have had a comment from you though !

Have fun,

Keith

---

Hi,

The new crediting system is - without the slightest doubt - extremely unfair for the so called long WUs (= VLAR WUs).

Well ...

Result #347054389
AR: 0.4355
cpu time: 53289 secs
granted credit: 61.97
credits/hour: 4.19

Result #347481116
AR: 0.0050
cpu time: 48372
granted credit: 58.69
credits/hour: 4.37

I get more credits per hour for the VLARs than for the standard 0.4x ARs. Your are right. That's really unfair ... ;-)

Regards,
Carsten

Replying to only a portion of post by Keith (SwissNic):

I guess that's a definition thing. I was led to believe the FLOP measurement was the same as defined by the CPU manufacturers. If that's so there's a wide difference in how many FLOPS your CPU does by machine cycle between model, make and series. It's also complicated by those extended instructions (MMX,SSE2)that can process bunches of them quickly. So maybe someone can clarify for both us? It would save me getting the wrong picture. Does anyone know if the Seti/Boinc FLOP is a synthetic thing or related to machine code concepts?

The term FLOPS is only really defined in terms of the particular benchmark which attempted to measure floating point performance.

What setiathome_enhanced is doing is counting floating point operations. If the standard application has a routine which loops i times and contains x floating point additions, y floating point multiplies, and z floating point exponentiations, the FLOP_counter value could be incremented by i * (x + y + z) at the exit from the routine. When someone builds an optimized application, that increment should not be changed even if the mix of operations is actually different. The count is to be treated as an estimation of useful work done so that all applications successfully doing the same WU can be granted the same credit.

Here's an actual formula used for the main count in Triplet finding:

analysis_state.FLOP_counter+=(10.0*numBinsAboveThreshold*numBinsAboveThreshold);

                                                            Joe

Excellent, so at least I know I'm speaking hot air and suffering from foot and mouth disease :-)

{Breathes a sigh of relief}

That's good. So it checkpoints and makes an artificial FLOP or should I say bunch of 'known' artificial FLOPS?

Do you reckon there's a way that extended instruction sets can confuse this ?
Just to clarify....

SwissNic, Saengar, Josef et al, my deepest apologies for mis-understanding! I'll reasses things. It was lovely to have your attention and perserverance !!

I'm going to take a night of it and have a good think; if I can resist going "Woah, even Jim-R responded" ;-) (Sorry! It's got to be a Seti BB celeb. issue thing{grin})

Thanks for all the help everyone! I'll think and come back with the right twists and 'balance' I hope!

That was truly a learning experience!!!! Cooooooooooooool!!!!!!!!...sorry, it's probably an 80's thing :-)

15 years in tech support and there's still more to learn.......

Have a good night everyone... or a good afternoon/morning etc.

Regards and much respect,

Keith

---

Hi,
I get more credits per hour for the VLARs than for the standard 0.4x ARs. Your are right. That's really unfair ... ;-)

Maybe for you... but you are welcome to crunch those suckers with me... ;)

---

Aloha, Uli

Hi,

I get more credits per hour for the VLARs than for the standard 0.4x ARs. Your are right. That's really unfair ... ;-)

Maybe for you...

Not only for me. For everybody who has an AMD processor.

But if you look at the VHARs it's exactly the other way round. Here are the Intels much better and are getting much more credits per hour compared to the 0.4x. I really wonder why nobody complains about that ... ;-)

Regards,
Carsten

Keith Jones said:
Not to put to fine a point on it, I'm getting the feeling you don't actually give a jot about credits. If so, why comment at all ? Surely it'd be something you'd just ignore?

As for the fast computer bit... well ermm.. I can hardly argue with that concept... but I don't see the relevance to what I was saying. Feel free to elucidate...

Heh, well, let me first clarify something. I wasn't specifically replying to your post.
It was more a general complaint about people complaining all the time about the credit system being "unfair" and being cry-babies.

/Vent on

And yes, even though I understand the need for some sort of credit system, as a comparing tool, reward, motivation, or whatever; I do not agree with people/groups that crunch only for the credits, and do credit races/wars, and come to the boards to bitch and cry when their RACs go down a quarter of a point.

I swear I'd like to smack them all in the face. Repeatedly. :p
/Vent off

Peace ;)

---

/Mav

We have lingered long enough on the shores of the cosmic ocean.
We are ready at last to set sail for the stars.
(Carl Sagan)

Not only for me. For everybody who has an AMD processor. (...)

Unfortunately i own an AMD processor (Athlon C Thunderbird @ 1400) and my experience is just the other way around - hmmm - and for the 3.4 GHz Prescott@work it is also not like the way you stated... hmmm... Voodoo?

---

Aloha, Uli

Be happy, don't do the math. ;)

---

/Mav

We have lingered long enough on the shores of the cosmic ocean.
We are ready at last to set sail for the stars.
(Carl Sagan)

Hi,

Voodoo?

No. It only shows that the performance for the VLARs and VHARs is really unpredictable. CPU x does a good job, CPU y is very poor. Which one should determine the "standard"?

Regards,
Carsten

(...) Which one should determine the "standard"?

Obviously not mine... :/

[edit] ...although they both do an extraordinary good job at Rosetta! ;)

---

Aloha, Uli

Hi,

Voodoo?

No. It only shows that the performance for the VLARs and VHARs is really unpredictable. CPU x does a good job, CPU y is very poor. Which one should determine the "standard"?

Regards,
Carsten

And to add to the unpredictability, this can happen on one particular angle range while another angle range near to it but slightly different could be the opposite way. I believe this is what the people here are seeing. In the plot on the Beta site that Pappa posted you can see a slight drop for all ar's below 0.200 (from app. 10 1/2 cr/hr to 9 1/2 cr/hr) but there are specific ar's where the cr/hr drops to app. 8 however there is a peak at 0.2080 of app. 16 cr/hr! All of these could be considered VLAR units!

What is even stranger is there are larger drops in credits/hour at various spots in the plot with a very large dip from about 0.6 to 1.1 ar, however it's funny I haven't seen a word on the forums by somebody complaining about these much larger drops in credits/hour!

I am reluctant to post the link to the information here without Pappa's permission as I don't know the bandwidth of the server it is on and I wouldn't want it overloaded by posting it here without asking. However it does make an interesting picture. All in all, I feel like it may be possible to correct for some of the misaligned credits, such as the general 1 cr/hr drop below 0.2 and the larger drop at AR's 0.6 to 1.1, however this would still leave the numerous larger spikes and dips at individual AR's. However if Berkeley corrects these drops in credits/hour then it would only be fair to correct the increase in credits/hour reported for wu's higher than 1.1 AR.

It looks like to get the credit situation leveled across the majority of angle ranges will require the server to take over the assigning of credits. This could be done by simply reporting the fpops without the multiplier and have the validator assign the credits using a variable multiplier based on AR. This would not eliminate all of the complaints but I believe it would clear up most of them.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

It seems intuitively obvious that we have at least two or three different meanings for the word "fair"

....

I think "equitable" is the best meaning....

Motion seconded.

---

Grant
Darwin NT

There'a always the simple solution - One Credit per WU

---

nem·e·sis (nĕm'ĭ-sĭs) pronunciation
n., pl. -ses (-sēz').

1. An opponent that cannot be beaten or overcome.

2. One that inflicts retribution or vengeance.

There'a always the simple solution - One Credit per WU

Then I'll recomend LeidenClassical, typical WU last's about 5 - 15 min on my puter. That'll be a credit booster ;)
Edit:
If pirates would have a better supply, they'd even beet them with only several seconds per WU;)

Why for those who wants more credits dont running core client 4.45 or 5.2.5.
You will claime much more credits, but not granted.
But you may be happyer.

Mike

---

With each crime and every kindness we birth our future.

But it IS all fair.
And for crying outloud, no matter what method is used to calculate credits, a fast computer will always make more credits than a slow one.
I don't thing it's so hard to understand, but oh well, I remember now, I must be a complete moron. ;)


Peace.

Not to put to fine a point on it, I'm getting the feeling you don't actually give a jot about credits. If so, why comment at all ? Surely it'd be something you'd just ignore?

It seems intuitively obvious that we have at least two or three different meanings for the word "fair"

When I read "fair" I think "equitable" -- that everyone has an equal chance of getting "easy" and "hard" work units, and that everyone who does a work unit gets the same credit.

Clearly, some read "fair" and see "equal" -- that an hour of crunching will return the same number of credits no matter how many "easy FLOPs" and "hard FLOPs" are involved.

Some read "fair" as "no less than I used to get when I ran an optimized app."

... and as a result, we're often talking past each other when we start saying "fair."

I think "equitable" is the best meaning....

Hi Ned!

I never thought I'd get a reply fron such a demonstrably balanced individual!
Cool! oops showing my age there ;-)

Equitable is a great term. Yeh I can try and work using that as the word but being realistic, my interpretation of fair, equal or equitable will suffer the same problem. It will be different for everyone else's. Maybe it's not a dictionary issue?

Somewhere, somehow there's got to be a base agreement that most,if not all, can live with without constantly hassling each other. I guess it's silver lining (possibly a needle in a haystack or holy grail!) but it's worth trying to find a bit of common ground to alleviate the simple stress points...

Gonna have to sign off soon, my new 'evaluation' toy is running out of juice ;-)

Nice to have had a comment from you though !

Have fun,

Keith

Cool. I'm flattered.

I'll be happy if we can just get everyone to start thinking that we might be using different definitions or meanings of the word "fair."

I don't know that we can all agree on one definition -- but at least if one of us says "fair" and means "equitable" and someone else says "fair" and really means "consistent" we can at least take that in consideration.

I think the credit system is equitable -- when low-credit units are sent out, we all have an equal chance of getting them. It isn't entirely consistent in terms of credits/hour, or we wouldn't have low-credit units.

-- Ned

---

There'a always the simple solution - One Credit per WU

One credit per HashClash Work-Unit (15 minutes or so).

One credit per CPDN Work-Unit (6 months or so).

Hmmm.....

---

There'a always the simple solution - One Credit per WU

One credit per HashClash Work-Unit (15 minutes or so).

One credit per CPDN Work-Unit (6 months or so).

Hmmm.....

Cross-Project stats parity is totally unnecessary, and a waste of time and effort.

---

nem·e·sis (nĕm'ĭ-sĭs) pronunciation
n., pl. -ses (-sēz').

1. An opponent that cannot be beaten or overcome.

2. One that inflicts retribution or vengeance.