Output file exceeds size limit

Message boards : Number crunching : Output file exceeds size limit
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 930669 - Posted: 3 Sep 2009, 19:55:41 UTC
Last modified: 3 Sep 2009, 19:56:16 UTC


I got some of this messages:

Computation for task xxxxxxxxxxxxxxxxxxxxxxx.170_0 finished
Output file xxxxxxxxxxxxxxxxxxxxxxx.170_0_0 for task xxxxxxxxxxxxxxxxxxxxxxx.170_0 exceeds size limit.
File size: 98251.000000 bytes. Limit: 65536.000000 bytes



If I looked well, this message came after in the task overview was a calculation error.

Just curious.. maybe someone know it..
This are the 'CUDA -12 Unknown error's?

ID: 930669 · Report as offensive
Profile HAL9000
Volunteer tester
Avatar

Send message
Joined: 11 Sep 99
Posts: 6533
Credit: 196,805,888
RAC: 57
United States
Message 930674 - Posted: 3 Sep 2009, 20:11:21 UTC - in response to Message 930669.  

I have seen people state that there is a limited amount of space for saving the results of the task & sometimes when that space is full it will stop processing it. Perhaps soemthign along those lines.
SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the BP6/VP6 User Group today!
ID: 930674 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 930675 - Posted: 3 Sep 2009, 20:25:28 UTC


I got now 22 errors:
[http://setiathome.berkeley.edu/results.php?hostid=4789793&offset=0&show_names=0&state=5]

An example:
[http://setiathome.berkeley.edu/result.php?resultid=1351231016]

<core_client_version>6.4.7</core_client_version>
<![CDATA[
<stderr_txt>
setiathome_CUDA: Found 4 CUDA device(s):
Device 1 : GeForce GTX 260
totalGlobalMem = 939196416
sharedMemPerBlock = 16384
regsPerBlock = 16384
warpSize = 32
memPitch = 262144
maxThreadsPerBlock = 512
clockRate = 1458000
totalConstMem = 65536
major = 1
minor = 3
textureAlignment = 256
deviceOverlap = 1
multiProcessorCount = 27
Device 2 : GeForce GTX 260
totalGlobalMem = 939261952
sharedMemPerBlock = 16384
regsPerBlock = 16384
warpSize = 32
memPitch = 262144
maxThreadsPerBlock = 512
clockRate = 1458000
totalConstMem = 65536
major = 1
minor = 3
textureAlignment = 256
deviceOverlap = 1
multiProcessorCount = 27
Device 3 : GeForce GTX 260
totalGlobalMem = 939261952
sharedMemPerBlock = 16384
regsPerBlock = 16384
warpSize = 32
memPitch = 262144
maxThreadsPerBlock = 512
clockRate = 1458000
totalConstMem = 65536
major = 1
minor = 3
textureAlignment = 256
deviceOverlap = 1
multiProcessorCount = 27
Device 4 : GeForce GTX 260
totalGlobalMem = 939261952
sharedMemPerBlock = 16384
regsPerBlock = 16384
warpSize = 32
memPitch = 262144
maxThreadsPerBlock = 512
clockRate = 1458000
totalConstMem = 65536
major = 1
minor = 3
textureAlignment = 256
deviceOverlap = 1
multiProcessorCount = 27
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX 260 is okay
SETI@home using CUDA accelerated device GeForce GTX 260
V12 modification by Raistmer
Priority of worker thread rised successfully
Priority of process adjusted successfully
Total GPU memory 939196416 free GPU memory 890363904
setiathome_enhanced 6.02 Visual Studio/Microsoft C++

Build features: Non-graphics CUDA VLAR autokill enabled FFTW USE_SSE x86
CPUID: AMD Phenom(tm) II X4 940 Processor

Cache: L1=64K L2=512K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3
libboinc: 6.3.22

Work Unit Info:
...............
WU true angle range is : 1.871585
After app init: total GPU memory 939196416 free GPU memory 890363904

Flopcounter: 10465959332527.379000

Spike count: 7
Pulse count: 1
Triplet count: 0
Gaussian count: 0

Wall-clock time elapsed since last restart: 139.5 seconds
class T_FFT<0>: total=6.04e+004, N=98108, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<8>: total=0.00e+000, N=3, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<16>: total=0.00e+000, N=5, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<64>: total=0.00e+000, N=23, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<256>: total=0.00e+000, N=91, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<512>: total=4.70e+001, N=181, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<1024>: total=1.26e+002, N=361, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<2048>: total=6.20e+001, N=53, <>=1 (1.00e+000), min=0 (0.00e+000)
class T_FFT<4096>: total=7.70e+001, N=211, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<8192>: total=5.66e+002, N=845, <>=0 (0.00e+000), min=0 (0.00e+000)
called boinc_finish

</stderr_txt>
<message>
<file_xfer_error>
<file_name>14se08ae.21969.331923.8.10.156_1_0</file_name>
<error_code>-131</error_code>
</file_xfer_error>

</message>
]]>

Validate state Invalid


ID: 930675 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 930712 - Posted: 3 Sep 2009, 23:13:32 UTC

The size limit is set so that tasks that are full of radar noise error out very quickly and very little time is wasted when there is no likely result.


BOINC WIKI
ID: 930712 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14542
Credit: 200,643,578
RAC: 874
United Kingdom
Message 930726 - Posted: 3 Sep 2009, 23:40:38 UTC - in response to Message 930712.  

The size limit is set so that tasks that are full of radar noise error out very quickly and very little time is wasted when there is no likely result.

John,

I would have thought that you of all people would know the difference between a -9 overflow (found 30 signals - exceeds the maximum array dimension set by the developers, for the reasons you state), which is a deliberate, designed exit route and no error....

....and an abend with reported error. As it happens, I have a similar error on one of my machines:

04-Sep-2009 00:02:24 [SETI@home] Computation for task 14se08ae.459.331923.9.10.5_0 finished
04-Sep-2009 00:02:24 [SETI@home] Output file 14se08ae.459.331923.9.10.5_0_0 for task 14se08ae.459.331923.9.10.5_0 exceeds size limit.
04-Sep-2009 00:02:24 [SETI@home] File size: 100973.000000 bytes. Limit: 65536.000000 bytes

As I'm sure you're aware, SETI copies the <workunit_header> in its entirety from the WU file to the result file. In my case the WU has such an enormity of <coordinate_t> ... </coordinate_t> blocks that the original data file size is 433 KB instead of the standard 367 KB. Since the excess data is 66 KB, it's no surprise that the total output file size exceeds the 64 KB maximum expectation.

The question is, why just the two files (one for me, and one for Sutaru)? I have 70+ WUs on this machine at the moment, and this is the only oversize one.

Addendum: now reported - task 1351331588.
Data file preserved for forensic examination.
ID: 930726 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 930747 - Posted: 4 Sep 2009, 1:28:11 UTC - in response to Message 930726.  

As it happens, I have a similar error on one of my machines:

04-Sep-2009 00:02:24 [SETI@home] Computation for task 14se08ae.459.331923.9.10.5_0 finished
04-Sep-2009 00:02:24 [SETI@home] Output file 14se08ae.459.331923.9.10.5_0_0 for task 14se08ae.459.331923.9.10.5_0 exceeds size limit.
04-Sep-2009 00:02:24 [SETI@home] File size: 100973.000000 bytes. Limit: 65536.000000 bytes

As I'm sure you're aware, SETI copies the <workunit_header> in its entirety from the WU file to the result file. In my case the WU has such an enormity of <coordinate_t> ... </coordinate_t> blocks that the original data file size is 433 KB instead of the standard 367 KB. Since the excess data is 66 KB, it's no surprise that the total output file size exceeds the 64 KB maximum expectation.

The question is, why just the two files (one for me, and one for Sutaru)? I have 70+ WUs on this machine at the moment, and this is the only oversize one.

Addendum: now reported - task 1351331588.
Data file preserved for forensic examination.

You and Sutaru are quick, as other hosts complete work from the same groups they will probably suffer the same fate. One host has already been hit for 2 cases from the same group as yours, 14se08ae.459.331923.9.10.7 and 14se08ae.459.331923.9.10.10.

IIRC there was an earlier episode of mb_splitter processes putting in more than the 108 coordinates to cover 107.374 seconds of work. The <time> fields for the coordinates should mostly differ by about 0.0000116. The mathematical difference should be 1/86400 but only having 7 digits past the radix point and some awkwardness of the timing interface to the recorder make it vary from ideal. The difference between the first and last coordinate times should be close to 108/86400 or 0.00125.
                                                                Joe

ID: 930747 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14542
Credit: 200,643,578
RAC: 874
United Kingdom
Message 930801 - Posted: 4 Sep 2009, 8:27:35 UTC - in response to Message 930747.  

IIRC there was an earlier episode of mb_splitter processes putting in more than the 108 coordinates to cover 107.374 seconds of work. The <time> fields for the coordinates should mostly differ by about 0.0000116. The mathematical difference should be 1/86400 but only having 7 digits past the radix point and some awkwardness of the timing interface to the recorder make it vary from ideal. The difference between the first and last coordinate times should be close to 108/86400 or 0.00125.
                                                                Joe


My file has 569 cordinate sets. The gaps are right - all between 0.0000113 and 0.0000119, with the average being 0.0000116 - but the endpoints are wrong: first 2454725.3484224, last 2454725.3549881, difference 0.0065657

I have those numbers in a spreadsheet (also the original header) if you're interested.
ID: 930801 · Report as offensive
Profile Link
Avatar

Send message
Joined: 18 Sep 03
Posts: 834
Credit: 1,807,369
RAC: 0
Germany
Message 930810 - Posted: 4 Sep 2009, 9:33:26 UTC

I've just got one 433KB WU, the header is 88181 Bytes long. Shall I abort it? It has already one "-131". WU 499482023
ID: 930810 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14542
Credit: 200,643,578
RAC: 874
United Kingdom
Message 930814 - Posted: 4 Sep 2009, 10:05:46 UTC - in response to Message 930810.  

I've just got one 433KB WU, the header is 88181 Bytes long. Shall I abort it? It has already one "-131". WU 499482023

May as well. You're not going to get a valid result out of it, whatever you do - even if you suspend BOINC and edit the header down to a sensible size, the chances of you drawing a wingmate willing to make the same correction are vanishingly small.

Better to dispose of it before crunching rather than afterwards.
ID: 930814 · Report as offensive
MarkJ Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 17 Feb 08
Posts: 1139
Credit: 80,854,192
RAC: 5
Australia
Message 930816 - Posted: 4 Sep 2009, 10:18:44 UTC - in response to Message 930726.  
Last modified: 4 Sep 2009, 10:25:56 UTC

The question is, why just the two files (one for me, and one for Sutaru)? I have 70+ WUs on this machine at the moment, and this is the only oversize one.


I had a bunch of wu giving -131 errors and a size limit message in the BOINC log. Not sure if these are related or not as I haven't dug any deeper yet. The machine in question got a new GTX295 installed that morning so it might be the cause.

wu 1
wu 2
wu 3

[edit]
The BOINC FAQ has the following to say about these:

ERR_FILE_TOO_BIG -131

One of the output files is bigger than the maximum set by the project for upload.
BOINC will not try to upload this file.

Solution: Go to the project's forums and report this behavior.

[/edit]
BOINC blog
ID: 930816 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14542
Credit: 200,643,578
RAC: 874
United Kingdom
Message 930821 - Posted: 4 Sep 2009, 10:55:58 UTC - in response to Message 930816.  

Solution: Go to the project's forums and report this behavior.

I've also sent a PM to Eric Korpela, linking this thread, as I don't think BOINC message boards are a reliable mechanism for getting information back to project developers and administrators - more's the pity.

[In spite of the wise advice in the BOINC documentation:

Take an active role in your web site's message boards. Read them frequently, and respond quickly ...

which is widely ignored by all and sundry, most conspicuously the BOINC developers themselves]
ID: 930821 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 930839 - Posted: 4 Sep 2009, 13:53:20 UTC
Last modified: 4 Sep 2009, 13:58:55 UTC


I took some time and searched..

The beginning all the same (21x) and one 'outsiders' at the end.

14se08ae.21969.331923.8.10.170_0
http://setiathome.berkeley.edu/result.php?resultid=1351231025
http://setiathome.berkeley.edu/workunit.php?wuid=499576943

14se08ae.21969.331923.8.10.159_1
http://setiathome.berkeley.edu/result.php?resultid=1351231018
http://setiathome.berkeley.edu/workunit.php?wuid=499576919

14se08ae.21969.331923.8.10.156_1
http://setiathome.berkeley.edu/result.php?resultid=1351231016
http://setiathome.berkeley.edu/workunit.php?wuid=499576913

14se08ae.21969.331923.8.10.146_0
http://setiathome.berkeley.edu/result.php?resultid=1351231009
http://setiathome.berkeley.edu/workunit.php?wuid=499576895

14se08ae.21969.331923.8.10.138_0
http://setiathome.berkeley.edu/result.php?resultid=1351231003
http://setiathome.berkeley.edu/workunit.php?wuid=499576877

14se08ae.21969.331923.8.10.135_0
http://setiathome.berkeley.edu/result.php?resultid=1351231001
http://setiathome.berkeley.edu/workunit.php?wuid=499576871

14se08ae.21969.331923.8.10.129_0
http://setiathome.berkeley.edu/result.php?resultid=1351230997
http://setiathome.berkeley.edu/workunit.php?wuid=499576859

14se08ae.21969.331923.8.10.120_0
http://setiathome.berkeley.edu/result.php?resultid=1351230991
http://setiathome.berkeley.edu/workunit.php?wuid=499576841

14se08ae.21969.331923.8.10.98_0
http://setiathome.berkeley.edu/result.php?resultid=1351230975
http://setiathome.berkeley.edu/workunit.php?wuid=499576793

14se08ae.21969.331923.8.10.95_1
http://setiathome.berkeley.edu/result.php?resultid=1351230974
http://setiathome.berkeley.edu/workunit.php?wuid=499576787

14se08ae.21969.331923.8.10.58_0
http://setiathome.berkeley.edu/result.php?resultid=1351230949
http://setiathome.berkeley.edu/workunit.php?wuid=499576715

14se08ae.21969.331923.8.10.55_0
http://setiathome.berkeley.edu/result.php?resultid=1351230947
http://setiathome.berkeley.edu/workunit.php?wuid=499576709

14se08ae.21969.331923.8.10.49_0
http://setiathome.berkeley.edu/result.php?resultid=1351230943
http://setiathome.berkeley.edu/workunit.php?wuid=499576697

14se08ae.21969.331923.8.10.40_0
http://setiathome.berkeley.edu/result.php?resultid=1351230937
http://setiathome.berkeley.edu/workunit.php?wuid=499576679

14se08ae.21969.331923.8.10.140_0
http://setiathome.berkeley.edu/result.php?resultid=1351230927
http://setiathome.berkeley.edu/workunit.php?wuid=499576881

14se08ae.21969.331923.8.10.134_0
http://setiathome.berkeley.edu/result.php?resultid=1351230923
http://setiathome.berkeley.edu/workunit.php?wuid=499576869

14se08ae.21969.331923.8.10.131_0
http://setiathome.berkeley.edu/result.php?resultid=1351230921
http://setiathome.berkeley.edu/workunit.php?wuid=499576863

14se08ae.21969.331923.8.10.128_0
http://setiathome.berkeley.edu/result.php?resultid=1351230919
http://setiathome.berkeley.edu/workunit.php?wuid=499576857

14se08ae.21969.331923.8.10.122_0
http://setiathome.berkeley.edu/result.php?resultid=1351230915
http://setiathome.berkeley.edu/workunit.php?wuid=499576845

14se08ae.21969.331923.8.10.119_0
http://setiathome.berkeley.edu/result.php?resultid=1351230913
http://setiathome.berkeley.edu/workunit.php?wuid=499576839

14se08ae.21969.331923.8.10.108_1
http://setiathome.berkeley.edu/result.php?resultid=1351230906
http://setiathome.berkeley.edu/workunit.php?wuid=499576815

..the 'outsiders':

14se08ae.11826.331923.7.10.174_2
http://setiathome.berkeley.edu/result.php?resultid=1351224624
http://setiathome.berkeley.edu/workunit.php?wuid=499525139



ID: 930839 · Report as offensive
Eric Korpela Project Donor
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 3 Apr 99
Posts: 1381
Credit: 54,506,847
RAC: 60
United States
Message 930884 - Posted: 4 Sep 2009, 17:24:19 UTC - in response to Message 930839.  

Apparently we have some bad data headers on that data file. I'll see whether we should stop processing it more if theres good data after the bad spot.

Eric
@SETIEric@qoto.org (Mastodon)

ID: 930884 · Report as offensive
MarkJ Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 17 Feb 08
Posts: 1139
Credit: 80,854,192
RAC: 5
Australia
Message 931045 - Posted: 5 Sep 2009, 0:45:36 UTC - in response to Message 930884.  

Apparently we have some bad data headers on that data file. I'll see whether we should stop processing it more if theres good data after the bad spot.

Eric


Well that explains it, at least its not my hardware :-)

Thanks for the reply
BOINC blog
ID: 931045 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51468
Credit: 1,018,363,574
RAC: 1,004
United States
Message 931047 - Posted: 5 Sep 2009, 0:47:35 UTC - in response to Message 931045.  

Apparently we have some bad data headers on that data file. I'll see whether we should stop processing it more if theres good data after the bad spot.

Eric


Well that explains it, at least its not my hardware :-)

Thanks for the reply

LOL......it couldn't possibly be my OC'd hardware.........could it? Nah.....
"Freedom is just Chaos, with better lighting." Alan Dean Foster

ID: 931047 · Report as offensive

Message boards : Number crunching : Output file exceeds size limit


 
©2023 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.