Message boards :
Number crunching :
Good and bad results on the same WU
Message board moderation
Author | Message |
---|---|
SETI User Send message Joined: 29 Jun 02 Posts: 369 Credit: 0 RAC: 0 ![]() |
Hello! Why it can be, that some PCs have a bad result and other PCs good/ correct result? ! The same WU ! Greetings! |
![]() ![]() Send message Joined: 7 Feb 06 Posts: 1494 Credit: 194,148 RAC: 0 ![]() |
Hello! All of the results gave errors, it's just in the way it was reported. If you will check all of the results, you will see the two "good" results actually have -9 overflow errors. This evidently led to several of the results to return Windows errors (the long negative number result code) while others didn't cause a Windows error but gave the -9 error instead. In reality a -9 is not considered an "error". Instead it means that the result is what is called a "noisy" result. Evidently this is an unusual work unit in that normally a "noisy" work unit is detected almost immediately instead of crunching as long as these obviously did before giving errors. Why did they do this? I have no clue! 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. |
Urs Echternacht ![]() Send message Joined: 15 May 99 Posts: 692 Credit: 135,197,781 RAC: 211 ![]() ![]() |
A -9 error is indicating that a wu has too much RFI (Radio Frequency Interference) in its data. Therefore it is called a noisy wu and if the number of results is higher than a threshold (ca. 30 results) the further work on this wu is aborted by the setiathome application. The threshold can be reached earlier or later while a wu is done and there seems to be a problem with the standard setiathome application v5.15 in returning the -9 error. _\|/_ U r s |
![]() ![]() Send message Joined: 7 Feb 06 Posts: 1494 Credit: 194,148 RAC: 0 ![]() |
The threshold can be reached earlier or later while a wu is done and there seems to be a problem with the standard setiathome application v5.15 in returning the -9 error. Thanks. This is what I was refering to when I said I had no clue. Meaning I dodn't know why some results gave the -9 error and others a Windows error code. (I run Linux so to be honest I haven't really kept up with the Windows postings. I guess I should read "all" posts just so I can keep up, but haven't had much free time lately!) And yes, I had meant to put in my original post that probably the "noise" didn't show up until late in the wu. This would explain why they crunched so long before giving the error. It could also be that it was just a lot of random noise scattered throughout the wu and it didn't reach the maximum signal count until late in the wu. 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. |
![]() Send message Joined: 2 Aug 00 Posts: 1851 Credit: 5,955,047 RAC: 0 ![]() |
My guess is that if there is one noisy unit collected at a certain date and time, all its 255 other bandmates will be noisy, too. The whole band is only 2.5 MHz wide which is only about 0.176 percent of its frequency. |
SETI User Send message Joined: 29 Jun 02 Posts: 369 Credit: 0 RAC: 0 ![]() |
All of the results gave errors, it's just in the way it was reported. If you will check all of the results, you will see the two "good" results actually have -9 overflow errors. This evidently led to several of the results to return Windows errors (the long negative number result code) while others didn't cause a Windows error but gave the -9 error instead. ... Hello! Thanks to all for the support! But, when you look to the WU: 3 got claimed credit and no granted credit, and 3 got claimed credit and granted credit too... Why? Greetings! |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 ![]() |
My guess is that if there is one noisy unit collected at a certain date and time, all its 255 other bandmates will be noisy, too. The whole band is only 2.5 MHz wide which is only about 0.176 percent of its frequency. For noise which is strong enough to saturate the receiver front end that's certainly true. But for lesser levels, noise tends to cluster at harmonics of a base frequency so it's quite likely that some bandmates will have excessive noise while others don't. I've seen a couple of cases of multiple WUs from the same tape and time where a small run of close subband numbers overflowed while more distant subbands didn't. I'd say that if one WU from a specific tape and time overflows, it means the chances of others from the same group overflowing are much higher. If the project had lots of money, equipment, and personnel they could probably do a database search to quantify the probability. Joe |
![]() ![]() Send message Joined: 13 Oct 00 Posts: 611 Credit: 2,025,000 RAC: 0 ![]() |
I think the point is, that those 3 result that have credits granted, are reported as "result overflow" (which is a "normal" computing result), where as the other 3 results have been reported with an exit status "c00005" (and therefore are not valid)... Regards Andy |
SETI User Send message Joined: 29 Jun 02 Posts: 369 Credit: 0 RAC: 0 ![]() |
|
Urs Echternacht ![]() Send message Joined: 15 May 99 Posts: 692 Credit: 135,197,781 RAC: 211 ![]() ![]() |
|
SETI User Send message Joined: 29 Jun 02 Posts: 369 Credit: 0 RAC: 0 ![]() |
|
![]() ![]() Send message Joined: 3 Apr 99 Posts: 2452 Credit: 33,281 RAC: 0 ![]() |
As I don't want to start a new thread, this one seems to be appropriate. Look at this WU: http://setiathome.berkeley.edu/workunit.php?wuid=88583452 369659302 2545615 21 Aug 2006 18:25:31 UTC 26 Aug 2006 2:35:31 UTC In Progress Unknown New --- --- --- 369659303 222527 21 Aug 2006 18:25:38 UTC 22 Aug 2006 6:16:27 UTC Over Success Done 42,244.36 3,559.45 3,559.45 369659304 140053 21 Aug 2006 18:25:38 UTC 22 Aug 2006 6:30:55 UTC Over Success Done 43,076.77 4,062.43 3,559.45 369659305 205498 21 Aug 2006 18:25:39 UTC 22 Aug 2006 2:59:43 UTC Over Success Done 3,129.72 15.09 3,559.45 I get it, that some cheaters happen to be coincidently in the same WU, and thus got exaggerated credits. That's unpropable, but not impossible, so it has to happen from time to time. The forth cruncher will be really happy ;) But... The two cheaters found nothing, neither spike, nor gaussian, triplet or pulse. The one with the reasonable claim found 3 spikes. How could they validate? Shouldn't they be to far apart with that results? Edit: Just had another look, and the two with the exorbitant claims seem to have crunched for about 10x as long as the other one, but the machines don't seem to be that far apart. Is this possible? And if so, how? And is it perhaps no cheating, but some severe bug where ever? Gruesse vom Saenger For questions about Boinc look in the BOINC-Wiki |
![]() ![]() Send message Joined: 13 Oct 00 Posts: 611 Credit: 2,025,000 RAC: 0 ![]() |
Maybe they found the "Wow!"-Signal... :o But to be serious: Doesn't look like cheating to me, since the other results of those 2 machines seems to be normal (as far as they don't have a compute error -5). Maybe a combination of BIONC Ver. 4.45 + optimized app + some hardware/software errors (e.g. while setting up the work directory)? |
Richard Haselgrove ![]() Send message Joined: 4 Jul 99 Posts: 14690 Credit: 200,643,578 RAC: 874 ![]() ![]() |
Note that both of the (alleged?) cheaters have a large number of "compute errors" in their WU history, but no particular sign of overclaiming credit - at least on the one computer we can see for each of them, given that the accounts are anonymous. Another possibility is that they're both overclocking beyond stability, and that has caused the extended run on the WU - and since they're both running BOINC 4.45, the credit claim has been based on time, not FLOPS. |
Richard Haselgrove ![]() Send message Joined: 4 Jul 99 Posts: 14690 Credit: 200,643,578 RAC: 874 ![]() ![]() |
Another strange thing. Computer 222527 picked up the WU at 18:25:38 on 21 Aug, and returned it at 6:16:27 on 22 Aug - 42649 seconds later. It says it worked on it for 42244 seconds, which is just possible. But it's only a single CPU computer, and it completed two other (reasonable time) WUs in between. Also, both rogue claims come from machines running Crunch3r's 5.12 optimized app, but Crunch3r's sig is missing from the result text on both results. I wish Crunch3r was still around to comment/explain. [edit - it completed three WUs in between... /edit] |
kittyman ![]() ![]() ![]() ![]() Send message Joined: 9 Jul 00 Posts: 51575 Credit: 1,018,363,574 RAC: 1,004 ![]() ![]() |
Note that both of the (alleged?) cheaters have a large number of "compute errors" in their WU history, but no particular sign of overclaiming credit - at least on the one computer we can see for each of them, given that the accounts are anonymous. One of my crunchers, an overclocked FX60 rig, has recently reported a number of workunits claiming about 8.900 points each. No cheating, has to be errors of some kind. Since I oc all my rigs to the edge, sometimes I get a few errors or crashes, then I back off the settings a bit. I have most of my rigs now to the point that they are running at about there maximum limit, and don't often end up with computation errors anymore. I am also running the Chicken op apps. My guess is that there have been some wu's lately that have required a bit more intensive processing than ususal, and a cpu that is overclocked a bit too much, perhaps combined with an optimized app, creates these results. You can look at the results for my FX60 if you want to check out a number of these overclaiming wu's. Of course, I have only been granted normal credit for these wu's, as the validator normally throws out credit claims that don't fit the norm reported for a particular wu. But in your reported case, with 2 users claiming an overinflated credit amount, the validator actually issued the bogus credit claims!! Curious bit...both overclaimers are running 4.45, one is an AMD, and the other is an Intel. And the 3rd user, that claimed a normal 15.09 credits, is the only one reporting using a Crunch3r app! Very curious! "Time is simply the mechanism that keeps everything from happening all at once." ![]() |
![]() ![]() Send message Joined: 13 Oct 00 Posts: 611 Credit: 2,025,000 RAC: 0 ![]() |
Maybe he has merged two or more computers to just one? Another possibility: He runs multiple copies of BOINC on one machine (by unsing any kind of "Virtual PC" stuff)... Would explain, how he's able to do multiple WU's in just the possible time. |
SETI User Send message Joined: 29 Jun 02 Posts: 369 Credit: 0 RAC: 0 ![]() |
Maybe he has merged two or more computers to just one? Hello! Hey, you must read the complete thread! It was because of the message: SETI@Home Informational message -9 result_overflow NOTE: The number of results detected exceeds the storage space allocated. The WU on different PCs Some PCs have this result message, some not. Because of a "S@H - bug" And then the PC get the Credits or not... I have since 15 Aug 2006, 22:22:28 UTC "Suse LINUX 10.1-64Bit" installed on my AMD K8. Together with Windows XP on my HDD. I wanted to test the performance of Simons Greetings! |
![]() ![]() Send message Joined: 13 Oct 00 Posts: 611 Credit: 2,025,000 RAC: 0 ![]() |
Yes, you're right! The "overclaimed credits"-posts (the six last posts except yours) should go in its own thread. Sorr for hijacking your thread! Regards Andy |
kittyman ![]() ![]() ![]() ![]() Send message Joined: 9 Jul 00 Posts: 51575 Credit: 1,018,363,574 RAC: 1,004 ![]() ![]() |
Yes, you're right! The "overclaimed credits"-posts (the six last posts except yours) should go in its own thread. My apologies as well, I was just replying to the most recent post that I read. Is it possible for a mod to extract those posts from this thread and put them in a 'overclaimed credits' thread? Or is that not possible? "Time is simply the mechanism that keeps everything from happening all at once." ![]() |
©2025 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.