One result of my PC was compared with this PC:
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
And a 3 result was sending out..

Then I saw that nearly all results of this PC will compare with 2 other results..
Why? What's going wrong with this PC?

---

and a Q6600 with L3 Cache?!?!?! or so the memory read speed section says!

---

Do you Good Search for Seti@Home? http://www.goodsearch.com/?charityid=888957
Or Good Shop? http://www.goodshop.com/?charityid=888957

One result of my PC was compared with this PC:
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
And a 3 result was sending out..

Then I saw that nearly all results of this PC will compare with 2 other results..
Why? What's going wrong with this PC?

If you look at selected work units, this returned 13 spikes and the other returned 13 spikes and a gaussian.

Or this machine returned one spike, and the other returned two.

That means the results were not strongly similar, and to figure out which is which, a third result is needed.

---

One result of my PC was compared with this PC:
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
And a 3 result was sending out..

Then I saw that nearly all results of this PC will compare with 2 other results..
Why? What's going wrong with this PC?

If you look at selected work units, this returned 13 spikes and the other returned 13 spikes and a gaussian.

Or this machine returned one spike, and the other returned two.

That means the results were not strongly similar, and to figure out which is which, a third result is needed.

But please look for examples to this results:

http://setiathome.berkeley.edu/workunit.php?wuid=266829464
http://setiathome.berkeley.edu/workunit.php?wuid=265464061
http://setiathome.berkeley.edu/workunit.php?wuid=265463854
http://setiathome.berkeley.edu/workunit.php?wuid=265463842
http://setiathome.berkeley.edu/workunit.php?wuid=265463864

They have the same result, but a 3 WU was sent..


The PC about I'm talking report the opt. app as V5.21
For example:

Optimized SETI@Home Enhanced application
Optimizers: Ben Herndon, Josef Segur, Alex Kan, Simon Zadra
[b]Linux port: Crunch3r, Hans Dorn, Simon Zadra
   Version: Linux 32-bit based on S@H V5.15  'Noo? No - Ni!'
  Revision: R-2.4L|xP|FFT:IPP_SSE3|Ben-Joe[/b]
     CPUID: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
      CPUs: 1, cores: 1,  cache: L1=32K,  L2=4096K
  Features: MMX  SSE  SSE2  SSE3   
     Speed: 2857 MHz  -- read MB/s: L1=10871, L2=10020, L3=9114, RAM=7836

Work Unit Info
WU Credit multi. is:  2.85
WU True angle range:  0.447445

Spikes Pulses Triplets Gaussians Flops
   1      0       0        0     15334878692493

</stderr_txt>
]]>
 
Validate state Checked, but no consensus yet 
Claimed credit 50.600236427784 
Granted credit 0 
[b]application version 5.21[/b]

Maybe he have a bad OC?
The flopcounter is to different?

---

I found a LINUX opt. app and a (MAC) stock app (other PCs):
http://setiathome.berkeley.edu/workunit.php?wuid=259211269

[EDIT]
This other LINUX PC:
Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (no OC) (nearly all results compared with 2 results also)
[/EDIT]


It cannot be a problem with the LINUX opt. app?

Because the problem with the upper Q6600 is with LINUX opt. app and compare with stock (Window) app..


Edit from the title of this thread also.. 'reference' to the LINUX opt. app

---

The PC about I'm talking report the opt. app as V5.21

I'm afraid you are mis-understanding the reporting process.

"application version 5.21" is derived from the app_info.xml 'anonymous platform' control file. It tells SETI that the application in use can handle data files designed for that app - it is irrelevant at this stage.

The actual application in use is:

Version: Linux 32-bit based on S@H V5.15 'Noo? No - Ni!'
Revision: R-2.4L|xP|FFT:IPP_SSE3|Ben-Joe

I'm not familiar with it - is it one of Crunch3r's? Maybe Crunch3r, or one of the Lunatics, can help us.

...
The actual application in use is:

Version: Linux 32-bit based on S@H V5.15 'Noo? No - Ni!'
Revision: R-2.4L|xP|FFT:IPP_SSE3|Ben-Joe

I'm not familiar with it - is it one of Crunch3r's? Maybe Crunch3r, or one of the Lunatics, can help us.

To my experiences the V and L from the Rev.2.4 came from Crunch3r..

---

That means the results were not strongly similar, and to figure out which is which, a third result is needed.

But please look for examples to this results:

No, I'm not going to look.

It's really simple. They were compared, they weren't close enough, so a third work unit was needed.

Why? Maybe there was more than one spike, and they both detected all of them, but at different strengths? Maybe they agreed on everything but the levels were off by too much.

Maybe it's a simple difference in the math coprocessors and how the different floating point units estimate things like SIN(). You knew they are estimates, right? They're not exact.

If it is your machine, then yeah, I'd look into it, but if it isn't your machine, then you aren't losing credit, and it doesn't affect anything that matters.

---

Host 3766033 and host 4302067 are using 2.4L builds without any weakly similar comparisons AFAICT. That suggests there's nothing fundamentally wrong with the builds. Perhaps the issue is some minor incompatibility with certain versions of Linux or perhaps the two hosts with problems have some weaknesses. The 2.4L builds have been in use for months, I cannot believe any major problem would have gone unnoticed this long.

                                                               Joe

That means the results were not strongly similar, and to figure out which is which, a third result is needed.

But please look for examples to this results:

No, I'm not going to look.

It's really simple. They were compared, they weren't close enough, so a third work unit was needed.

Why? Maybe there was more than one spike, and they both detected all of them, but at different strengths? Maybe they agreed on everything but the levels were off by too much.

Maybe it's a simple difference in the math coprocessors and how the different floating point units estimate things like SIN(). You knew they are estimates, right? They're not exact.

If it is your machine, then yeah, I'd look into it, but if it isn't your machine, then you aren't losing credit, and it doesn't affect anything that matters.

Maybe the science is slower?

---

Host 3766033 and host 4302067 are using 2.4L builds without any weakly similar comparisons AFAICT. That suggests there's nothing fundamentally wrong with the builds. Perhaps the issue is some minor incompatibility with certain versions of Linux or perhaps the two hosts with problems have some weaknesses. The 2.4L builds have been in use for months, I cannot believe any major problem would have gone unnoticed this long.

                                                               Joe

Thank you for clear this..

The only reason to post the problem was to support..

---

If it is your machine, then yeah, I'd look into it, but if it isn't your machine, then you aren't losing credit, and it doesn't affect anything that matters.

Maybe the science is slower?

I did not bold the comment in my original post. If you are going to modify what you are quoting, please take out the "quote" markers.

This is a "feature" of any kind of volunteer computing effort.

Look how zealous some people are about crunching as much work as possible: every single "overclocked" computer is running on reduced margins, and if the people running them know what they're doing, there is enough margin left -- or maybe not.

The individual crunchers are not "qualified" by the project in any way. They have no way of knowing how good computers really are "in the wild."

So, every bit of work must be confirmed by at least two computers -- and the results must match.

If that wasn't true, the work units could be issued once, not validated against a second work unit, and we'd go twice as fast.

Then again, the only way for the project to qualify the computers is for the project to buy them. That means no SETI@HOME.

So, this is how it works. You can accept that as the nature of volunteer computing, or you can obsess over the fact that life isn't perfect -- and that is something you can't fix.

---

Look how zealous some people are about crunching as much work as possible: every single "overclocked" computer is running on reduced margins, and if the people running them know what they're doing, there is enough margin left -- or maybe not.

The individual crunchers are not "qualified" by the project in any way. They have no way of knowing how good computers really are "in the wild."

I should clarify: I'm not being critical of overclockers -- or anything done to squeeze more performance out of a machine.

The key concept is "in the wild" -- the machines doing the crunching are all over the map: they're fast, they're slow, they're well maintained, they're basically ignored. They belong to SETI enthusiasts and people who are barely aware of SETI. They're single machines, or part of a huge network. They're monitored hourly, and they've been on autopilot for years.

SETI@Home does not know a lot about them, so every result needs to be verified carefully.

Quick Science is good, Quick and Accurate is better.

---