Ned, you recently made a comment that seems germane.
I'll change it slightly to more fit this exact exchange.

Just because we know we can't find a perfect solution, does that imply we should stop looking for solutions that are better than what we have now?

Of course not. FLOPS is better than what came before, therefore we use it. There is a known solution better than FLOPS, therefore we should use it.
Especially since it would allow us to solve or at least minimize a real problem we are presently having.

An improvement that solves or allows for the solution to a substatial problem is a Good Thing.

Even if it is not perfect.

---

Ned, you recently made a comment that seems germane.
I'll change it slightly to more fit this exact exchange.

Just because we know we can't find a perfect solution, does that imply we should stop looking for solutions that are better than what we have now?

Of course not. FLOPS is better than what came before, therefore we use it. There is a known solution better than FLOPS, therefore we should use it.
Especially since it would allow us to solve or at least minimize a real problem we are presently having.

An improvement that solves or allows for the solution to a substatial problem is a Good Thing.

Even if it is not perfect.

Certainly all true, and BOINC does provide a third method of credit calculation based on benchmark values reported by the science application.

For this project, the recent "First annual fundraising drive" brought in about a third of a year's worth of contributions. The project personnel will continue to do what they can, but adding significant work to their load is not likely.

Perhaps your efforts would be better directed to encouraging some of the 99% of participants who have not yet contributed to do so.

                                                           Joe

Ned, you recently made a comment that seems germane.
I'll change it slightly to more fit this exact exchange.

Just because we know we can't find a perfect solution, does that imply we should stop looking for solutions that are better than what we have now?

Of course not. FLOPS is better than what came before, therefore we use it. There is a known solution better than FLOPS, therefore we should use it.
Especially since it would allow us to solve or at least minimize a real problem we are presently having.

An improvement that solves or allows for the solution to a substatial problem is a Good Thing.

Even if it is not perfect.

I agree, and I'll also say that trying to achieve perfection is a worthy goal.

That's the optimist in me. The realist says "and while it's a great goal, it is unreachable."

That's when I start saying "what can we do that's close...."

Your suggestion about measuring performance through some known work unit is basically just changing the benchmark, and it adds complexity because each project now needs their own benchmark, each suited to that project.

We either have to somehow measure equal work units, or everyone crunches the "reference" unit for calibration.

So I don't see a real value going back to a benchmark * cpu time because it all hinges on a really good benchmark that doesn't depend on the processor architecture.

---

Just because we know we can't find a perfect solution, does that imply we should stop looking for solutions that are better than what we have now?

Of course not. FLOPS is better than what came before, therefore we use it. There is a known solution better than FLOPS, therefore we should use it.
Especially since it would allow us to solve or at least minimize a real problem we are presently having.

An improvement that solves or allows for the solution to a substatial problem is a Good Thing.

Even if it is not perfect.

Eric Korpela already did make a comment it would have been better to put the multiplier in wu instead of the seti-application. This would have made it very easy to increase/decrease as needed, and increase/decrease for specific angle-ranges while others is fixed.



But, would this have solved all the problems?

No, let's look on the "real" problem, as I've already mentioned before, the "real" problem is that different seti-wu has different amount of the various calculations, and one specific computer can be "excellent" on example pulse-finding but awful on gaussians, while another computer can be exactly opposite.

For data, I've used info from VLAR's on beta-forum and Winternight's 'normalized' crunch-times for various angle-ranges

1; My Opteron, compared to "old" seti-v4.18, Seti_Enhanced with different angle-ranges har roughly cpu-times:
a; VHAR, 0.5x-0.6x.
b; Ar=0.42 is around 2.6x.
c; VLAR is around 3.0x.

2; Winterknight's Pentium-M:
a; VHAR, 0.35x.
b; Ar=0.42 is 2.2x.
c; VLAR is around 3.2x.

3; Winterknight's P3:
a; VHAR, 0.6x-0.7x.
b; Ar=0.42 is 2.1x.
c; VLAR is around 3.2x.

Now, if example says ar=0.42 is worth 60 CS, what will happen if makes granted credit linear with cpu-time on one of the computers?

Example, using my computer as linear => VLAR = 69.23 CS, VHAR = 12.69 CS.
=> 1a = 1b = 1c = 7.29 CS/h. (used 3h10m with v4.18).

P-M; 2a = 17.41 CS/h (7500s with v4.18)
2b = 13.09 CS/h
2c = 10.38 CS/h

P3; 3a = 2.52 CS/h (27900s with v4.18)
3b = 3.69 CS/h
3c = 2.79 CS/h

And this again means, if my computer is kept linear, the Pentium-M gives 32.97% more credit/hour on VHAR than on "normal" angle-ranges, and gives 20.67% less credit/hour on VLAR, and 67.6% more credit/hour on VHAR than on VLAR...
Also, very surprisingly, the P3 gives 31.66% less credit/hour on VHAR than on "normal" angle-ranges, and 24.28% less credit/hour on VLAR. "Normal" angle-ranges is actually giving more credit/hour than either of the end-points...

You can of course switch which computer gets the constant CS/h, if Pentium-M is constant => VLAR = 87.27 CS, VHAR = 9.54 CS.
=> Pentium-M = 13.09 CS/h.
Opteron, 1a = 5.49 CS/h, 1b = 7.29 CS/h, 1c = 9.19 CS/h => gets 26% more on VLAR than "normal", and 24.8% less on VHAR than on "normal"... Yes, the "worst" wu will be the shortest-ones...
P3, 3a = 1.89 CS/h, 3b = 3.69 CS/h, 3c = 3.52 CS/h => gets 4.54% less on VLAR, and 48.6% less on VHAR... Meaning, P3 gets nearly 2x more credit/hour on "normal" angle-ranges than on the shortest wu...

Lastly, putting P3 as linear => VLAR = 91.42 CS, VHAR = 18.57 CS
=> P3 = 3.69 CS/h.
Opteron, 1a = 10.66 CS/h, 1b = 7.29 CS/h, 1c = 9.62 CS/h => gets 32.1% more on VLAR, and 46.3% more on VHAR than on "normal" angle-ranges.
Pentium-M, 2a = 25.47 CS/h, 2b = 13.09 CS/h, 2c = 13.71 CS/h => gets 4.8% more on VLAR than "normal", and 94.6% more on VHAR than on "normal"...



Meaning, bottom line is, as long as a specific wu gets the same credit regardless of which computer it's crunched on, you'll have the problem that for one angle-range an individual computer will get more credit/hour than for another angle-range.

So, knowing the problem... Do you have a solution that will make the problem significantly better, so much better that it's worth the programming-time to implement, debug, and use?


BTW, one immediate suggestion can be application-specific benchmark, BOINC already supports this. But, as BOINC alpha has shown, even re-running the exact same seti-wu on the exact same computer, can give over 30% variation in reported cpu-times. Meaning, anything that relies on cpu-time won't be significantly better than "flops-counting".

For data, I've used info from VLAR's on beta-forum and Winternight's 'normalized' crunch-times for various angle-ranges

1; My Opteron, compared to "old" seti-v4.18, Seti_Enhanced with different angle-ranges har roughly cpu-times:
a; VHAR, 0.5x-0.6x.
b; Ar=0.42 is around 2.6x.
c; VLAR is around 3.0x.

2; Winterknight's Pentium-M:
a; VHAR, 0.35x.
b; Ar=0.42 is 2.2x.
c; VLAR is around 3.2x.

3; Winterknight's P3:
a; VHAR, 0.6x-0.7x.
b; Ar=0.42 is 2.1x.
c; VLAR is around 3.2x.

Now, if example says ar=0.42 is worth 60 CS, what will happen if makes granted credit linear with cpu-time on one of the computers?

Example, using my computer as linear => VLAR = 69.23 CS, VHAR = 12.69 CS.
=> 1a = 1b = 1c = 7.29 CS/h. (used 3h10m with v4.18).

P-M; 2a = 17.41 CS/h (7500s with v4.18)
2b = 13.09 CS/h
2c = 10.38 CS/h

P3; 3a = 2.52 CS/h (27900s with v4.18)
3b = 3.69 CS/h
3c = 2.79 CS/h

And this again means, if my computer is kept linear, the Pentium-M gives 32.97% more credit/hour on VHAR than on "normal" angle-ranges, and gives 20.67% less credit/hour on VLAR, and 67.6% more credit/hour on VHAR than on VLAR...
Also, very surprisingly, the P3 gives 31.66% less credit/hour on VHAR than on "normal" angle-ranges, and 24.28% less credit/hour on VLAR. "Normal" angle-ranges is actually giving more credit/hour than either of the end-points...

You can of course switch which computer gets the constant CS/h, if Pentium-M is constant => VLAR = 87.27 CS, VHAR = 9.54 CS.
=> Pentium-M = 13.09 CS/h.
Opteron, 1a = 5.49 CS/h, 1b = 7.29 CS/h, 1c = 9.19 CS/h => gets 26% more on VLAR than "normal", and 24.8% less on VHAR than on "normal"... Yes, the "worst" wu will be the shortest-ones...
P3, 3a = 1.89 CS/h, 3b = 3.69 CS/h, 3c = 3.52 CS/h => gets 4.54% less on VLAR, and 48.6% less on VHAR... Meaning, P3 gets nearly 2x more credit/hour on "normal" angle-ranges than on the shortest wu...

Lastly, putting P3 as linear => VLAR = 91.42 CS, VHAR = 18.57 CS
=> P3 = 3.69 CS/h.
Opteron, 1a = 10.66 CS/h, 1b = 7.29 CS/h, 1c = 9.62 CS/h => gets 32.1% more on VLAR, and 46.3% more on VHAR than on "normal" angle-ranges.
Pentium-M, 2a = 25.47 CS/h, 2b = 13.09 CS/h, 2c = 13.71 CS/h => gets 4.8% more on VLAR than "normal", and 94.6% more on VHAR than on "normal"...



Meaning, bottom line is, as long as a specific wu gets the same credit regardless of which computer it's crunched on, you'll have the problem that for one angle-range an individual computer will get more credit/hour than for another angle-range.

So, knowing the problem... Do you have a solution that will make the problem significantly better, so much better that it's worth the programming-time to implement, debug, and use?

Right now, there is a scaling factor that is used to convert FLOPs to credits, and as I remember, that scaling factor is 3.35 in 5.15, and will be closer to 3.5 in the next version.

If instead, we had a different scaling factor for VLAR, mid-range, and VHAR work units, then we could get closer to a flat credit/hour value.

It probably wouldn't be perfect, but it'd be closer.

I see <true_angle_range> in the work unit header....

---

Right now, there is a scaling factor that is used to convert FLOPs to credits, and as I remember, that scaling factor is 3.35 in 5.15, and will be closer to 3.5 in the next version.

The scaling-factor is 3.35 now, 3.51 in v5.17.

If instead, we had a different scaling factor for VLAR, mid-range, and VHAR work units, then we could get closer to a flat credit/hour value.

It probably wouldn't be perfect, but it'd be closer.

I see <true_angle_range> in the work unit header....

But as my results from 3 different computers just showed, if you do adjust the scaling-factor for the various angle-ranges so a particular computer gives the same credit/hour across all angle-ranges, another computer can still give 1.5x-2x more credit/hour for the "best" angle-range compared to the "worst" angle-range...

As long as 2 different computers both uses example 6h at angle-range=0.42, but one of them uses 2h and the other 1h at angle-range>1.5, regardless of what you changes the multiplier to for VHAR, one of the computers will have either a significant advantage or a significant disadvantage crunching VHAR compard to ar=0.42.

quoting EricVonDaniken:
If you "hoard" easier tasks to boost your RAC / standing / whatever, you hurt every cruncher who plays "fair", and therefore the entire community, and therefore the entire project.

OK, I'll bite - precisely how does terminating a particular work unit (regardless of the reason) in proper fashion, so that the scheduler can reissue it as appropriate, hurt "the entire community and therefore the entire project"?

"everyone has the Right to be different as long as they do not adversely affect anyone else's Right to be different".
If you cross that line, you are doing Something Wrong.

While that sounds good statement in principle, it's actually pretty meaningless in actual application. One could as easily use the same argument to support the position that anyone who does not do everything within their capability to maximize their credit is doing Something Wrong, as it adversely affects the "Right to be different" of those who do wish to.

When that Something Wrong involves the credit system that is used as the primary non-scientific motivator for this game we call "BOINC" or "seti",
then it is rightfully called cheating because it violates the "rules" we have agreed to play by.

Could you please provide a pointer to those "rules" that you say we have agreed to play by? I can't seem to find any reference to what you're referring to on the "Rules and Policies" page at http://setiathome.berkeley.edu/info.php.

Anyone involved with Ars Technica should be educated and smart enough to grok.

Actually, I haven't "grokked" since the late 60's or early 70's, when I learned to understand instead. Not that either are particularly necessary requirements for membership in Ars Technica or any other distributed computing team - but I'm speaking for myself here, and noone else.

Do try understand what I'm about - I'm not condoning the practice under discussion. At best it's inconsiderate, if not outright rude. Perhaps it's just that the term "cheating" doesn't bear the same connotation today for people who've grown up (or otherwise become immersed) in "electronic society" - what with the "cheat codes" passed around by gamers, outright theft of intellectual property, and similar practices that seem to be so pervasive. But there are still some of us old pharts, and perhaps even some not-so-old pharts, for whom "cheating" is a strong accusation. In some circles, being found cheating will still result in you being found the next morning - as will unsupported accusations of cheating.

quoting DarkStar: IMHO, we all need to get this "c" word out of our collective vocabularies, and quit tossing it around quite so handily.

Yea, the c word is bad. That is, if by that you mean "credits". :p

---

/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)

Ingleside:
Am wading through the mountains of data implied by your post.
Will reply to your post after I've finished analysis and had a chance to think about the implications.
It's going to take a while.

Darkstar:
I, like you, also do not use the word "cheat" lightly. Nor do I have much appreciation of the word being used lightly.
That's one of the reasons I'm a tad peeved at the public cheating accusations levelled at Crunch3r; and one of the reasons I'm sounding off about cheating and accusations of cheating that are far too casual for my tastes.
When I am not trying to help find a fix for some of the current technical problems, I will be happy to continue our discussion.
Side Note: ...and where did or do =you= play cards/dice/gamble/etc for money?
(that being the most obvious place I know where the issue of cheating can get someone killed.)

---

Right now, there is a scaling factor that is used to convert FLOPs to credits, and as I remember, that scaling factor is 3.35 in 5.15, and will be closer to 3.5 in the next version.

The scaling-factor is 3.35 now, 3.51 in v5.17.

If instead, we had a different scaling factor for VLAR, mid-range, and VHAR work units, then we could get closer to a flat credit/hour value.

It probably wouldn't be perfect, but it'd be closer.

I see <true_angle_range> in the work unit header....

But as my results from 3 different computers just showed, if you do adjust the scaling-factor for the various angle-ranges so a particular computer gives the same credit/hour across all angle-ranges, another computer can still give 1.5x-2x more credit/hour for the "best" angle-range compared to the "worst" angle-range...

As long as 2 different computers both uses example 6h at angle-range=0.42, but one of them uses 2h and the other 1h at angle-range>1.5, regardless of what you changes the multiplier to for VHAR, one of the computers will have either a significant advantage or a significant disadvantage crunching VHAR compard to ar=0.42.

... and I think that's always going to be true.

We think that all x86 processors have a common architecture, and that just isn't true -- or you wouldn't have an AMD and an Intel processor running the same "speed" with different clocks.

But it would probably be better.

---

quoting EricVonDaniken:
Darkstar:
I, like you, also do not use the word "cheat" lightly. Nor do I have much appreciation of the word being used lightly.

Then on that much, at least, we can agree.

Side Note: ...and where did or do =you= play cards/dice/gamble/etc for money? (that being the most obvious place I know where the issue of cheating can get someone killed.)

It's mostly "did" rather than "do" (and don't forget to include dominos and nine ball to the "etc.") As to where, I think I'll take the fifth (rather appropriate since many such altercations are accompanied by various spirits that tend to come in fifth-size containers or multiples thereof).

The scaling-factor is 3.35 now, 3.51 in v5.17.

But, But 5.17 does not now exist. Eric is working real hard on this, but the number of changes are daunting. When he sends 5.17 to Beta I will crunch it to death with my antiquoe machines.