Output file exceeds size limit
Message boards :
Number crunching :
Output file exceeds size limit
Message board moderation
| Author | Message |
|---|---|
 Dirk Sadowski Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 
|
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 ·  |
HAL9000  Send message Joined: 11 Sep 99 Posts: 6534 Credit: 196,805,888 RAC: 57 
 |
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 [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[
ID: 930674 · |
|
Dirk Sadowski Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5
|
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 · |
John McLeod VII  Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0
|
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 · |
Richard Haselgrove  Send message Joined: 4 Jul 99 Posts: 14680 Credit: 200,643,578 RAC: 874 
 |
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 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 · |
|
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0
|
As it happens, I have a similar error on one of my machines: 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 · |
|
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14680 Credit: 200,643,578 RAC: 874
|
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 · |
Link  Send message Joined: 18 Sep 03 Posts: 834 Credit: 1,807,369 RAC: 0
|
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 · |
|
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14680 Credit: 200,643,578 RAC: 874
|
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 · |
MarkJ     Send message Joined: 17 Feb 08 Posts: 1139 Credit: 80,854,192 RAC: 5 
|
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 [/edit] BOINC blog ID: 930816 · |
|
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14680 Credit: 200,643,578 RAC: 874
|
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 · |
|
Dirk Sadowski Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5
|
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 · |
Eric Korpela  Send message Joined: 3 Apr 99 Posts: 1382 Credit: 54,506,847 RAC: 60
|
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 · |
|
MarkJ Send message Joined: 17 Feb 08 Posts: 1139 Credit: 80,854,192 RAC: 5
|
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. Well that explains it, at least its not my hardware :-) Thanks for the reply BOINC blog ID: 931045 · |
kittyman  Send message Joined: 9 Jul 00 Posts: 51488 Credit: 1,018,363,574 RAC: 1,004
|
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. LOL......it couldn't possibly be my OC'd hardware.........could it? Nah..... "Time is simply the mechanism that keeps everything from happening all at once." 
ID: 931047 · |
©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.