There is now an English version of the blog entry I've mentioned before on some sociologically (and otherwise) interesting points about the strike, thanks to Dr. Christoph Jansen.
You'll find it at http://fischer.uni-hd.de/efcblog/special/seti_strike.htm. Have a look ...

Great read I must say.

Yea... If you're in to one sided biased commentaries maybe....

This is a piece that does not even begin to consider the motivations of why people crunch for reasons OTHER then pure science, and actually insults the others who do not crunch purely for science by equating their reasons for involvement with "Dick Length"....WTF kind of unbiased crap journalism is that...? Yea it's his opinion but it could have been less abrasive and more objective and still would have gotten his point across.

http://fischer.uni-hd.de/efcblog/special/seti_strike.htm

SETI credits do not mean anything in the "real world": they are insubstantial, you cannot eat them and you cannot buy anything with them at all. They are just abstract numbers (and defined in a pretty complicated way). This does not keep a certain species of technology lovers and overclockers from gathering whole computer farms for the sole purpose of crunching for SETI (and other distributed computing projects based on Berkeley's open BOINC platform), to keep up in the electronic dick length comparison. If you follow the respective fora, you cannot quite help but feel that for some people hunting for credits means a vital purpose in their lives. The science done using their calculations has become practically irrelevant.

I'd like to add a new perspective to the discussion about distributing over-claiming seti applications:

V 5.11 right from the source..

I guess someone needs to pull this version, too.


Regards Hans

That build is for the BETA project not main. Notice BETA in the URL. Also every BETA build from 4.00 to 5.15 is in that directory as well. 5.11 was not ment to be run on the main project.

B E T A

Why try and stoke the flames with this?

---

This is a piece that does not even begin to consider the motivations of why people crunch for reasons OTHER then pure science, and actually insults the others who do not crunch purely for science by equating their reasons for involvement with "Dick Length"....

Well, it says also:

It sure is fun to watch one's own credit accumulate and to overtake others in the overall ranking; the competitive element drives the users' commitment.

I know that because I feel that way, too. I'm still sad that I've never even got my 1000 WU badge at SETI Classic, but at the same time I'm totally aware that it doesn't mean anything really.

As for d*** length: It does seem to be a male thing in the first place, doesn't it? What's your gender?

There is now an English version of the blog entry I've mentioned before on some sociologically (and otherwise) interesting points about the strike, thanks to Dr. Christoph Jansen.
You'll find it at http://fischer.uni-hd.de/efcblog/special/seti_strike.htm. Have a look ...

It's strange that there is no mention of all the "science" that is done by all the credit freaks; the amount is quite substantcial and has benefited the project tremendously.

---

Account frozen...

It's strange that there is no mention of all the "science" that is done by all the credit freaks; the amount is quite substantcial and has benefited the project tremendously.

It sure has. Thus:

It was already then that the idea of a strike was coined to emphasize the demand for more valuable credits: the volunteers achieving the most for the project (and who suffered from the new credit system more than the average user) must not be the ones punished; the project team would have to yield to the demands of their participants they were after all depending on!

They can be twisted into a device to just plain attempt to cheat, even if only by a few tenths or even whole amounts of cobblestones per wu. (example, one user with an AMD64 3200 OCed just reported a benchmark of Measured floating point speed 3760 million ops/sec Measured integer speed 11460.0 million ops/sec, my AMD64 3700 reports 2k/4k with a stock boinc client. My app does a wu in 1 hour and unless his does one in 20 minutes then this user is cheating).

TONY have you not learned ANYTHING from this 'discussion"? Calling someone a "cheater" REQUIRES proof. Just because the numbers are out of whack does NOT mean they are cheating. ALL computers get re-benchmarked every 7 days. Why would that be if the project developers don't think that the numbers can be off? Okay the numbers above are WAY OFF. STILL does not mean they are "cheating"! I checked on a Mac the other day, the guy had a whatever Mac that was taking 4 to hours to do units and had an RAC of around 150. My FASTEST machine has an RAC of 735.26, currently. The numbers are: Measured floating point speed 1190.07 million ops/sec, Measured integer speed 1414.12 million ops/sec. His were WAAAAAY more than that and he was taking longer to do units on average! Am I "cheating"? NEVER GONNA HAPPEN!!! Was/is the other guy "cheating", maybe but there is NO PROOF!!! His numbers are out of whack, that is all! BTW my machine is an Intel P4 D940 EE, meaning dual core Intel with HT on each core. Why are YOUR numbers so high?
Here are the numbers for one of my AMD 64 3000's: Measured floating point speed 1729.73 million ops/sec, Measured integer speed 3227.18 million ops/sec.
Why are you at 24/14 for a 3700? I am also using ONLY stock clients!!!And have been since Enhanced came along, before that I used Crunch3rs apps on most of my machines. The app has nothing to do with the benchmarking.
In short Tony, I think more info is needed before this goes any further.

---

http://fr.boincstats.com/stats/user_graph.php?pr=sah&id=11044

hummm beginning August 2004 ===> the end June 2006

22 month very virus C++ !

CRUNCH3R ARG!! 5 years of prison

---

SETI@Home Informational message -9 result_overflow
with a general handicap of 80% and it makes much d' efforts for the community and s' expimer, thank you d' to be understanding.

TONY have you not learned ANYTHING

Mikey, Earlier in this thread you posted

But if Berkeley were to require that no optimized app be released before being peer reviewed then it may have negated this whole situation we are now in. I agree it is more work, but maybe if you did a conference call with the optimizers and gave them some guidelines and had them peer review it among themselves BEFORE releasing it to the public, it might help.

I was posting that so you'd see it was thought of earlier and DR. A simply responded to the effect that our new Fpops system would be taking care of this.

That's all, the other info was posted so you had the full info to read. Actually at that time Boinc Alpha was looking for something to do rather than just rerunning the seti app which we already knew worked. After all, we're testing Boinc, not Seti. Part of why this was submitted was to say "hey, we could test the optimized app on Boinc Alpha".

tony

TONY have you not learned ANYTHING

Mikey, Earlier in this thread you posted

But if Berkeley were to require that no optimized app be released before being peer reviewed then it may have negated this whole situation we are now in. I agree it is more work, but maybe if you did a conference call with the optimizers and gave them some guidelines and had them peer review it among themselves BEFORE releasing it to the public, it might help.

I was posting that so you'd see it was thought of earlier and DR. A simply responded to the effect that our new Fpops system would be taking care of this.

That's all, the other info was posted so you had the full info to read. Actually at that time Boinc Alpha was looking for something to do rather than just rerunning the seti app which we already knew worked. After all, we're testing Boinc, not Seti. Part of why this was submitted was to say "hey, we could test the optimized app on Boinc Alpha".

tony

Okay, as I am sure you are aware I am not a part of any Alpha or Beta testing right now. I was a Beta tester i nthe past but not for a long time and have never been an alpha tester. Thankyou for clearing that up. Yes I think Berkeley missed the boat on that issue!

---

and you're right, if berkeley had tested the apps for scientific validity, and the optimized boinc clients for "credit equality" and function, then this might have been avoided.

Which as you said was suggested to them long ago. Maybe now it will finally happen. There are now others that, reportedly, are considering making optimized apps for the Seti, and other, projects. This could be another situation developing if they, Berkeley, don't get a handle on this.

---

So, how long do you guys figure it will take before Seti gets the new version fixed?

---

So, how long do you guys figure it will take before Seti gets the new version fixed?

define fixed.

MS still releases updates and patches every other week, so they're still trying to get it right. LOL

Okay, as I am sure you are aware I am not a part of any Alpha or Beta testing right now. I was a Beta tester i nthe past but not for a long time and have never been an alpha tester. Thankyou for clearing that up. Yes I think Berkeley missed the boat on that issue!

Berkeley didn't "miss the boat on that issue". They were aware of it and made a decision to not compound the problems that would come up with the new Enhanced Appliction.

They have known for months that BOINC Client versions prior to 5.2.6 would "correct" the applications credit calculations. They could have forced the change prior to the release, but I'm sure that more pressing issues kept them from doing so.

Somewhere I believe is a posting from Matt that basically said that they would look into this later if it became a problem.

---

and you're right, if berkeley had tested the apps for scientific validity, and the optimized boinc clients for "credit equality" and function, then this might have been avoided.

Which as you said was suggested to them long ago. Maybe now it will finally happen. There are now others that, reportedly, are considering making optimized apps for the Seti, and other, projects. This could be another situation developing if they, Berkeley, don't get a handle on this.

Part of having the science application be "open source" is so that people on different platforms can compile their own, and people who want to try to speed things up can do that as well.

Which means that there theoretically can be thousands of binaries out there that were compiled by someone else (most of which are not being distributed).

... but if you think about it, the quorum system is a "peer review" of sorts. To get credit, your result must match two other machines.

---

Okay, as I am sure you are aware I am not a part of any Alpha or Beta testing right now. I was a Beta tester i nthe past but not for a long time and have never been an alpha tester. Thankyou for clearing that up. Yes I think Berkeley missed the boat on that issue!

Berkeley didn't "miss the boat on that issue". They were aware of it and made a decision to not compound the problems that would come up with the new Enhanced Appliction.

They have known for months that BOINC Client versions prior to 5.2.6 would "correct" the applications credit calculations. They could have forced the change prior to the release, but I'm sure that more pressing issues kept them from doing so.

Somewhere I believe is a posting from Matt that basically said that they would look into this later if it became a problem.

Just a little correction, Boinc versions prior to 5.2.6 do not read the "fpops" results so they still use the "benchmarks" to claim credit, causing them to report widely varying and excessivee amounts of credits. Of course the quorum usually catches this and will kick out the exaggerated credit claim.
The reason that up to now Berkeley hasn't required that newer versions be used is that the new versions of Boinc are released only for mainstream computers. Users with other computers must use older versions until someone ports the newest versions to those systems. Anyone capable of doing ports to various os's? Until then we will either continue to have the occasional high credit claim from these older versions or we will loose a lot of crunchers that have systems that are not supported in the main release.

---

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.

Okay, as I am sure you are aware I am not a part of any Alpha or Beta testing right now. I was a Beta tester i nthe past but not for a long time and have never been an alpha tester. Thankyou for clearing that up. Yes I think Berkeley missed the boat on that issue!

Berkeley didn't "miss the boat on that issue". They were aware of it and made a decision to not compound the problems that would come up with the new Enhanced Appliction.

They have known for months that BOINC Client versions prior to 5.2.6 would "correct" the applications credit calculations. They could have forced the change prior to the release, but I'm sure that more pressing issues kept them from doing so.

Somewhere I believe is a posting from Matt that basically said that they would look into this later if it became a problem.

Just a little correction, Boinc versions prior to 5.2.6 do not read the "fpops" results so they still use the "benchmarks" to claim credit, causing them to report widely varying and excessivee amounts of credits. Of course the quorum usually catches this and will kick out the exaggerated credit claim.
The reason that up to now Berkeley hasn't required that newer versions be used is that the new versions of Boinc are released only for mainstream computers. Users with other computers must use older versions until someone ports the newest versions to those systems. Anyone capable of doing ports to various os's? Until then we will either continue to have the occasional high credit claim from these older versions or we will loose a lot of crunchers that have systems that are not supported in the main release.

I could be mistaken, but a clearer description of situation (as I understand it) might be this:

The application reports "Here's my result information including CPU time and the Credits I want to claim."

The old BOINC Client is saying "You don't know what you're talking about. Your CPU time, my Benchmark, and various other factors say that the Credits should be xx.xx and that's what I'm going to report."

I agree that blocking "old" BOINC Clients could cause problems. Luckily I don't have to make the decision and take any of the resulting heat.

---

[
The application reports "Here's my result information including CPU time and the Credits I want to claim."

The old BOINC Client is saying "You don't know what you're talking about. Your CPU time, my Benchmark, and various other factors say that the Credits should be xx.xx and that's what I'm going to report."

Very well put. The Seti application *reports* both cpu time *and* fpops, however the older Boinc clients don't know what to do with the fpops figure so it just uses the cpu time and benchmarks to calculate credits the same as the earlier applications.

I agree that blocking "old" BOINC Clients could cause problems. Luckily I don't have to make the decision and take any of the resulting heat.

Me neither!!! Haha!!!

---

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.

Just a little correction, Boinc versions prior to 5.2.6 do not read the "fpops" results so they still use the "benchmarks" to claim credit, causing them to report widely varying and excessivee amounts of credits. Of course the quorum usually catches this and will kick out the exaggerated credit claim.

The old clients’ claims aren’t always higher; like everything else it seems, for any particular WU the discrepancy depends on AR. I believe it’s for VHAR WUs that you’ll see v4.x clients claiming less than do the more current BOINCs.

---

Just a little correction, Boinc versions prior to 5.2.6 do not read the "fpops" results so they still use the "benchmarks" to claim credit, causing them to report widely varying and excessivee amounts of credits. Of course the quorum usually catches this and will kick out the exaggerated credit claim.

The old clients’ claims aren’t always higher; like everything else it seems, for any particular WU the discrepancy depends on AR. I believe it’s for VHAR WUs that you’ll see v4.x clients claiming less than do the more current BOINCs.

Yes, it has to do with the CPU time reported to the BOINC Client. The lower the CPU time the lower the Credits claimed.

---