We've all got it for WU 320848817 - three x stock v6.03, and my AK_V8 SSSE3x.

It appears in the message log as:

SETI@home 26/08/2008 21:09:14 Computation for task 22jl08aa.24540.207012.4.8.188_2 finished
SETI@home 26/08/2008 21:09:14 Output file 22jl08aa.24540.207012.4.8.188_2_0 for task 22jl08aa.24540.207012.4.8.188_2 exceeds size limit.
SETI@home 26/08/2008 21:09:14 File size: 72161.000000 bytes. Limit: 65536.000000 bytes

I'm not worried if there's only one of it (unless the file is so big because it contains the signal from ET, of course!), but we ought to report it if we see a lot of them.

We've all got it for WU 320848817 - three x stock v6.03, and my AK_V8 SSSE3x.

It appears in the message log as:

SETI@home 26/08/2008 21:09:14 Computation for task 22jl08aa.24540.207012.4.8.188_2 finished
SETI@home 26/08/2008 21:09:14 Output file 22jl08aa.24540.207012.4.8.188_2_0 for task 22jl08aa.24540.207012.4.8.188_2 exceeds size limit.
SETI@home 26/08/2008 21:09:14 File size: 72161.000000 bytes. Limit: 65536.000000 bytes

I'm not worried if there's only one of it (unless the file is so big because it contains the signal from ET, of course!), but we ought to report it if we see a lot of them.

Here are a couple that were reported a week ago: Message 799367
wuid=316574417
wuid=312048949

---

wuid=321214337

Here's one I just DL'd... has -131 error by 3 previous crunchers.

Noticed WU filesize is 411 KB rather than the standard 367 KB.

I'll make a copy of the WU available for anyone interested.

Regards,
JDWhale

---

wuid=321214337

Here's one I just DL'd... has -131 error by 3 previous crunchers.

Noticed WU filesize is 411 KB rather than the standard 367 KB.

I'll make a copy of the WU available for anyone interested.

Regards,
JDWhale

All of the <workunit_header> is copied to the output file, that's slightly less than 22000 bytes in normal WUs. If it grew by the difference in overall sizes, the output file would be close to the limit even before any signals were added. From the difference, the header contents might be duplicated about twice.

If you don't spot the problem, I'd certainly like to look.

                                                                 Joe

wuid=321214337

Here's one I just DL'd... has -131 error by 3 previous crunchers.

Noticed WU filesize is 411 KB rather than the standard 367 KB.

I'll make a copy of the WU available for anyone interested.

Regards,
JDWhale

All of the <workunit_header> is copied to the output file, that's slightly less than 22000 bytes in normal WUs. If it grew by the difference in overall sizes, the output file would be close to the limit even before any signals were added. From the difference, the header contents might be duplicated about twice.

If you don't spot the problem, I'd certainly like to look.

                                                                 Joe

Offhand I see ~409 instances of <coordinate_t> totaling ~52KB in header??

@Joe - See PM for link to WU.

---

FWIW, here's another. 321089386

Four -131 errors seem to have occurred on my E8400 while I was at school:

320848807
320848720
320848655
320848601

curiously, all these WU names seem to have the prefix 22jl08aa.24540.207012.4.8... Dodgy 'tape'?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Four -131 errors seem to have occurred on my E8400 while I was at school:

320848807
320848720
320848655
320848601

curiously, all these WU names seem to have the prefix 22jl08aa.24540.207012.4.8... Dodgy 'tape'?

The one John captured is 22jl08aa.21878.207012.8.8.128 (different splitter process, same "last block", different channel).

The splitter provides coordinates for the duration of the WU at 1 second intervals, so normally 108 of them to cover the 107.37 second duration. These run for 410 seconds, suggesting a timing problem at one end or the other. It's a little over 5 minutes of extra coordinates.

Perhaps the recording was paused for 5 minutes so the beginning and end of the data were actually that far apart? The splitter should only produce work from continuous recording, though. I think the process which makes the data returned from Arecibo into individual 'tape' segments is supposed to catch any pause and start a new 'tape'. Perhaps it missed the 5 minute pause and the splitter doesn't do a sanity check.

                                                               Joe

[edit]The server status page shows that 6 channels have been split from the 22jl08aa 'tape'. Assuming all channels will do the same at that part of the data, 1536 WUs have been produced with the problem. With the error causing additional replications of the WUs, that will be 9216 results overall. If the splitters are allowed to do the other 8 channels, that will be another 12288.

Hmmmm.... we had this problem once before and I thought it had been fixed. I'll grab the WU and check it out.

Eric

wuid=321214337

Here's one I just DL'd... has -131 error by 3 previous crunchers.

Noticed WU filesize is 411 KB rather than the standard 367 KB.

I'll make a copy of the WU available for anyone interested.

Regards,
JDWhale

---

@SETIEric@qoto.org (Mastodon)

If it helps, here's another that got the error.

-Dave

---

wuid=321342238

Hmmm... This one is strange... 3 hosts returned -131 error, but one host seems successful returning the result regardless of the error.

Have adjustments been made to the servers so quickly ?

---

FWIW, here's another -131 error code

http://setiathome.berkeley.edu/workunit.php?wuid=320924483

<message>

<file_xfer_error>
  <file_name>22jl08aa.6858.207012.5.8.1_4_0</file_name>
  <error_code>-131</error_code>
</file_xfer_error>

</message>

---

wuid=322221628

Guess Berkeley is still sending these out....

Here's another one where the first 2 hosts returned the -131 error, but one host sucessfully returned result while the other did not.

Why the different behavior???

---

wuid=322221628

Guess Berkeley is still sending these out....

Here's another one where the first 2 hosts returned the -131 error, but one host sucessfully returned result while the other did not.

Why the different behavior???

For more weirdness, look closer at the stderr.txt for the 'Success' Result.

<file_xfer_error>
<file_name>22jl08aa.5889.207012.10.8.235_1_0</file_name>
<error_code>-131</error_code>
</file_xfer_error>

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

For more weirdness, look closer at the stderr.txt for the 'Success' Result.

<file_xfer_error>
<file_name>22jl08aa.5889.207012.10.8.235_1_0</file_name>
<error_code>-131</error_code>
</file_xfer_error>

Wouldn't that suggest some abnormal thing between stock 6.03 and AK_V8 since the succesfull one is done with stock 6.03?

For more weirdness, look closer at the stderr.txt for the 'Success' Result.

<file_xfer_error>
<file_name>22jl08aa.5889.207012.10.8.235_1_0</file_name>
<error_code>-131</error_code>
</file_xfer_error>

Wouldn't that suggest some abnormal thing between stock 6.03 and AK_V8 since the succesfull one is done with stock 6.03?

Here's another one,
-131 error code
WU's
Here is the result, if it's inpossible to reach the adresses,
[i] v_BaseLineSmooth (no other)
v_vGetPowerSpectrumUnrolled 0.00006 0.00000
sse3_ChirpData_ak 0.00866 0.00000
v_vTranspose4 0.00187 0.00000
AK SSE folding 0.00064 0.00000

Flopcounter: 5369207707666.695300

Spike count: 1
Pulse count: 0
Triplet count: 0
Gaussian count: 0
called boinc_finish

</stderr_txt>
<message>
<file_xfer_error>
<file_name>22jl08aa.11591.207012.7.8.187_5_0</file_name>
<error_code>-131</error_code>
</file_xfer_error>

</message>
]]>

---

For more weirdness, look closer at the stderr.txt for the 'Success' Result.

<file_xfer_error>
<file_name>22jl08aa.5889.207012.10.8.235_1_0</file_name>
<error_code>-131</error_code>
</file_xfer_error>

Wouldn't that suggest some abnormal thing between stock 6.03 and AK_V8 since the succesfull one is done with stock 6.03?

I guess that would depend on exactly what a -131 error is... from the code:

#define ERR_FILE_TOO_BIG -131
// an output file was bigger than max_nbytes

suggests sanity checking failed in both cases, presumably due to a suspect WU of some kind... In this case the 'Success' is erroneous, it should be marked as a computation error as occurs with other faulty WUs.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Another, not -131, ERROR, more 'standard'
ERROR + Debug
WU

---

Another, not -131, ERROR,
ERROR + Debug

Looks like that one might have started with 6.02, then tried to finish, and crashed with 6.03?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Another, not -131, ERROR,
ERROR + Debug

Looks like that one might have started with 6.02, then tried to finish, and crashed with 6.03?

Think you're right Jason, did upgrade and didn't use an opti app. yet, so I can have a look at the graphics.
This shouldn't happen, though. I'll have to find out what version I used before.
Could be 6.2.12/14, though.
Here's another one,
Result
WU

---