ok, i raised the transfer limit to 1500,00 MB per day !? will that effect anything ?

ok i found this , but will taht help, i even dont understand that.

http://boinc.berkeley.edu/trac/wiki/JobSubmission

Two here as well!
20/12/2012 12:30:29 a.m. | GPUGRID | Output file 1x13_10-NOELIA_hfXA_long-0-2-RND5009_0_4 for task 1x13_10-NOELIA_hfXA_long-0-2-RND5009_0 exceeds size limit.
20/12/2012 12:30:29 a.m. | GPUGRID | File size: 144107276.000000 bytes. Limit: 128000000.000000 bytes
20/12/2012 11:49:34 a.m. | GPUGRID | Output file 1x31_12-NOELIA_hfXA_long-0-2-RND4384_1_4 for task 1x31_12-NOELIA_hfXA_long-0-2-RND4384_1 exceeds size limit.
20/12/2012 11:49:34 a.m. | GPUGRID | File size: 144107276.000000 bytes. Limit: 128000000.000000 bytes
And for sure on my other computer failed one as well.

Is there a possibility, to identify the WUs GDF has corrected? The failed ones took me over 11 hours to crunch.

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.

Nothing can be done client-side. I don't know if any modifications done server-side (I guess that a restart is needed) will actually reflect on already distributed workunits...

[EDIT]

I have a wu crunching since ~7 hours and I hope I will not lose it.... I found inside "client_state.xml" some lines about the "name_of_the_wu_4" which is the larger of the output files made while crunching: <max_nbytes>128000000.000000</max_nbytes> will change the value to a much larger one, restart boinc and see what happens...

I've just had another one fail at upload!!! :(

And a 3rd one :(

i wend wrong

So the situation is this one.

All the new WUs SENT after we have made the change this morning are ok.

The ones that were already queued in your client before this morning in Barcelona have a 50% probability of failing the upload, so cancel them.

gdf

Check this file in client_state.xml
128000000.000000

So the situation is this one.

All the new WUs SENT after we have made the change this morning are ok.

The ones that were already queued in your client before this morning in Barcelona have a 50% probability of failing the upload, so cancel them.

gdf

or try what I suggested a few posts ago....

Yes do that.

gdf

I have a wu crunching since ~7 hours and I hope I will not lose it.... I found inside "client_state.xml" some lines about the "name_of_the_wu_4" which is the larger of the output files made while crunching: <max_nbytes>128000000.000000</max_nbytes> will change the value to a much larger one, restart boinc and see what happens...

I did it, and it's working!

1. Exit BOINC manager with stopping scientific applications
2. Locate the client.xml file and open it with a text editor
-- On Windows XP: notepad.exe "C:\Documents and Settings\All Users\Application Data\BOINC\client_state.xml"
-- On Windows 7: notepad.exe "C:\Program Data\BOINC\client_state.xml"
3. Search and replace the <max_nbytes>128000000.000000</max_nbytes> value to <max_nbytes>198000000.000000</max_nbytes>
4. Save and Exit
5. Restat BOINC manager.

now it must be right.

<file>
    <name>1x29_7-NOELIA_hfXA_long-0-2-RND2127_2_4</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>256000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>

Crunshing this task, for sure it will work again.

Why are you not using <max_nbytes>0.000000</max_nbytes> ?

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

I did not even know about it.

gdf

Ok... i´m new on this beautifull project, and i´m not secure about editing things... But I understand that I can go back to long runs because the ones that are beeing splited now will work without any change?
I had a lot of 10/11 hr processing wasted and dont want to loose it all again..

I finally got one to upload successfully, after 4 failures, and with 3 more crunching!!!



http://www.gpugrid.net/result.php?resultid=6241005

Yes they are back running, you can crunch on.

---

DSKAG Austria Research Team: http://www.research.dskag.at

Thank you mate, they are reporting fine now!

On 20 Dec 12, GDF wrote...

All the new WUs SENT after we have made the change this morning are ok.

So, just to make sure, I should be okay having downloaded WU 6224269 on 21 Dec, even though it was created on 19 Dec?

Thanks,

MarkR

---

@ritterm - It should be ok. It's the "sent time" that counts for this issue.

You can anyway check the parameter, as above, to be sure.

@ritterm - It should be ok. It's the "sent time" that counts for this issue.

You can anyway check the <max_nbytes> parameter, as above, to be sure.

Thanks, Toni. I checked the client_state file and there appear to be numerous files with different <max_nbytes> settings for the WU. Again, just so I'm sure I've got this right, the output file is the one ending in "_4"? If so, I think I'm okay:

<file>
<name>10x6_4-NOELIA_hfXA_long-0-2-RND8944_0_4</name>
<nbytes>0.000000</nbytes>
<max_nbytes>256000000.000000</max_nbytes>
<status>0</status>
<upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>

---

I had one of these failures too today:

<core_client_version>7.0.28</core_client_version>
<![CDATA[
<stderr_txt>
MDIO: cannot open file "restart.coor"
# Time per step (avg over 6250000 steps): 	15.773 ms
# Approximate elapsed time for entire WU:  	98580.515 s
03:24:41 (23694): called boinc_finish

</stderr_txt>
<message>
upload failure: <file_xfer_error>
  <file_name>1x3_1-NOELIA_hfXA_long-0-2-RND0218_1_4</file_name>
  <error_code>-131</error_code>
</file_xfer_error>

</message>
]]>

100,000 seconds of work down the toilet... :( Please fix this!