However, it could be easily fixed by manually editing these numbers with a text editor (it is advised to exit BOINC manager & the scientific applications before doing so).

Agreed. It would be required to exit BOINC first (stopping the client - the Manager doesn't matter), before making the edit - very carefully, and using only a plain-text editor. Client_state.xml is only ever read by BOINC at start-up - it's effectively a hard-copy backup file, so any edits made while the BOINC client is running are overwritten by the next dump from memory.

I think we should wait for confirmation that a real problem exists (or doesn't, as the case may be) before advocating wholesale file editing. I did send a PM to Gerard after my last post here, suggesting that he monitors the early returns, but I haven't received any feedback yet.

However, it could be easily fixed by manually editing these numbers with a text editor (it is advised to exit BOINC manager & the scientific applications before doing so).

Agreed. It would be required to exit BOINC first (stopping the client - the Manager doesn't matter), before making the edit - very carefully, and using only a plain-text editor. Client_state.xml is only ever read by BOINC at start-up - it's effectively a hard-copy backup file, so any edits made while the BOINC client is running are overwritten by the next dump from memory.

I think we should wait for confirmation that a real problem exists (or doesn't, as the case may be) before advocating wholesale file editing. I did send a PM to Gerard after my last post here, suggesting that he monitors the early returns, but I haven't received any feedback yet.

It is proven:

23/01/2015 16:47:23 | GPUGRID | Computation for task 4x14-GERARD_VERYLONG_CXCL12_confAna-0-1-RND7430_0 finished
23/01/2015 16:47:23 | GPUGRID | Output file 4x14-GERARD_VERYLONG_CXCL12_confAna-0-1-RND7430_0_9 for task 4x14-GERARD_VERYLONG_CXCL12_confAna-0-1-RND7430_0 exceeds size limit.
23/01/2015 16:47:23 | GPUGRID | File size: 186931932.000000 bytes.  Limit: 128000000.000000 bytes

I was afraid so. What's more, the error is declared immediately after the task finishes: I was hoping that possibly disabling networking as the task approaches completion would buy enough time for an edit, but evidently not.

OK, time for those who read the forums to get out their editors, and a supply of resent tasks (which will themselves need editing) from those who don't.

It sounds like the batch is bad.
The cancellation, and rebatching, should all be done server-side.

OK, so here are the KISS ('Keep it simple, stupid') instructions.

1) Check if you are running a GPUGrid task with 'GERARD_VERYLONG_CXCL12_confAna' in the task name - or if you have one waiting to start. If you can't see one anywhere, relax and do nothing (except maybe open a beer).

2) If you have one of these tasks, read to the end of these instructions. If you feel confident about following them and carrying out the (very simple) edit required - carry on. If you don't feel confident, abort the task - running without editing it is a waste of time.

3) OK, you've decided to edit. First, shut down BOINC, making sure that the science applications shut down as well.

4) Find the file 'client_state.xml' in your BOINC Data folder. Under Windows, this is likely - if you accepted the default installation setting - to be C:\Programdata\BOINC: under Linux, it might be /var/lib/boinc

5) Open client_state.xml for editing, using a plain-text editor. Under Windows, NotePad or one of its replacements like NotePad++ is recommended - linux users are on their own here, but probably know their own toolsets.

6) Search the file for that GERARD_VERYLONG_CXCL12_confAna text we started with. There will be many search hits: we are looking for a <file>...</file> section like this:

<file>
    <name>2x23-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3250_0_9</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>128000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>

7) Make sure you have exactly the right section: the last number before </name> should be _9, and there should be an <upload_url> line.

8) Change the first three numbers after <max_nbytes> from 128 to 256. Just those three numbers - don't accidentally delete any punctuation, change the number of zeroes, or make any other change.

9) Repeat steps (6), (7) and (8) for each separate VERYLONG task that you have on the system.

10) Save the file, restart BOINC, and relax. All done.

It sounds like the batch is bad.
The cancellation, and rebatching, should all be done server-side.

And they possibly will be. But in the meantime, we can do something to help.

Look at the opening post in this thread: these are an urgent research challenge, "whose results we need as soon as possible (we are in a hurry)". That was over 24 hours ago, and many tasks will be approaching completion. We can save them, and get good data back today or tomorrow. If we have to go through the batch recall process (with the weekend already started in Barcelona), it'll probably be Tuesday before any results are returned. Why wait?

While your instructions are very well laid out, manual intervention is something that a lot of people probably won't be doing, in my estimation.

Thus, I would think the majority of the tasks out there, will go to completion, then fail, even if a handful of experts attempt client state manipulation.

This means that:
a) GPUGrid won't get the "task failed" notice until after the task ran
b) GPUGrid won't get the full batch of results that they are requesting
c) GPUGrid will be relying on user intervention to save the day.

Instead, it seems most appropriate, to me, for them to immediately cancel the batch and re-issue a corrected one. Why wait? :)

I'm not trying to pick an argument. Really. I'm just pointing out the option that, if I were admin'ing, I might choose to do.

4) Find the file 'client_state.xml' in your BOINC Data folder. Under Windows, this is likely - if you accepted the default installation setting - to be C:\Programdata\BOINC: under Linux, it might be /var/lib/boinc

As the ProgramData folder is hidden, it's easier to make a shortcut to notepad, which immediately opens the client_state.xml for editing:
1. right click on an empty area of your desktop
2. select new -> shortcut
3. enter the follwing text to the input field:
C:\Windows\System32\notepad.exe c:\ProgramData\BOINC\client_state.xml
4. click next
5. enter a self-explanatory name for this shortcut: edit client_state.xml

Instead, it seems most appropriate, to me, for them to immediately cancel the batch and re-issue a corrected one. Why wait? :)

Because I for one would resent the waste of 20 hours of perfectly salvageable crunching. Save what can be saved, and only reissue the remainder. This project tends to attract people with a pretty high level of motivation: let them demonstrate that their skill level matches their determination, before you condemn them all as incapable. But I agree - many tasks will fail, simply because not enough people will pick up news of the problem from this thread - unless the admins can post a second news item flagged to appear as a Notice?

You could just open File Explorer, and then in the address bar, type "%ProgramData%" (without the double-quotes).

While your instructions are very well laid out, manual intervention is something that a lot of people probably won't be doing, in my estimation.

Thus, I would think the majority of the tasks out there, will go to completion, then fail, even if a handful of experts attempt client state manipulation.

This means that:
a) GPUGrid won't get the "task failed" notice until after the task ran
b) GPUGrid won't get the full batch of results that they are requesting
c) GPUGrid will be relying on user intervention to save the day.

Instead, it seems most appropriate, to me, for them to immediately cancel the batch and re-issue a corrected one. Why wait? :)

I'm not trying to pick an argument. Really. I'm just pointing out the option that, if I were admin'ing, I might choose to do.

I agree.
The instructions intended for those who want to save 20+ hours of crunching.
If the project aborts the batch, those pieces which are under processing won't be aborted, only those which are sitting in the queue.

I will follow your instructions.
I have just one 'VERYLONG'.

---

I agree.Most wont even know. I last checked on mine about 7.5 hrs in all seamed well. Next time I had a chance to check on it it was competed. When I came to the site to see how long it did actually take I found it of course did not upload. So 17.5 hrs wasted. Bummer :( It uploaded at 15.41 UTC so the info was too late for me

Please do not panic. I'm going to discuss this issue with my superiors. I'll keep you updated.

Thank you to Richard Haselgrove, Retvari Zoltan* and Jacon Klein for their explanation, pro-activity and involvment.

Have updated the "client_state" for the 5 "GERARD VERY LONG" I have.

Hope, if it works, that they won't cancel the whole badge !

First 2 results in about 3h30 and 5h15 ...

Best,

Phil1966

OK, so here are the KISS ('Keep it simple, stupid') instructions.

4) Find the file 'client_state.xml' in your BOINC Data folder. Under Windows, this is likely - if you accepted the default installation setting - to be C:\Programdata\BOINC: under Linux, it might be /var/lib/boinc

5) Open client_state.xml for editing, using a plain-text editor. Under Windows, NotePad or one of its replacements like NotePad++ is recommended - linux users are on their own here, but probably know their own toolsets.

6) Search the file for that GERARD_VERYLONG_CXCL12_confAna text we started with. There will be many search hits: we are looking for a <file>...</file> section like this:

<file>
    <name>2x23-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3250_0_9</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>128000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>

7) Make sure you have exactly the right section: the last number before </name> should be _9, and there should be an <upload_url> line.

8) Change the first three numbers after <max_nbytes> from 128 to 256. Just those three numbers - don't accidentally delete any punctuation, change the number of zeroes, or make any other change.

9) Repeat steps (6), (7) and (8) for each separate VERYLONG task that you have on the system.

10) Save the file, restart BOINC, and relax. All done.

Thank you guys for bringing this info out, I'm hoping by the time I get home I will be able to make the edits in time. Like others have stated it is wasteful to use all this energy only to fail during upload.

6) Search the file for that GERARD_VERYLONG_CXCL12_confAna text we started with. There will be many search hits: we are looking for a <file>...</file> section like this:

<file>
    <name>2x23-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3250_0_9</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>128000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>

7) Make sure you have exactly the right section: the last number before </name> should be _9, and there should be an <upload_url> line.

8) Change the first three numbers after <max_nbytes> from 128 to 256. Just those three numbers - don't accidentally delete any punctuation, change the number of zeroes, or make any other change.

9) Repeat steps (6), (7) and (8) for each separate VERYLONG task that you have on the system.

10) Save the file, restart BOINC, and relax. All done.

Richard,
Why is it that max_nbytes only needs to be change for the _9 file, and not the others? - TIA

<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_1</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>50000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_2</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>50000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_3</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>50000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_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>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_5</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>10000000.000000</max_nbytes>
    <status>0</status>
    <gzip_when_done/>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_6</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>10000000.000000</max_nbytes>
    <status>0</status>
    <gzip_when_done/>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_7</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>10000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_8</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>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_9</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>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_10</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>10000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>
<file>
    <name>2x10-GERARD_VERYLONG_CXCL12_confAna-0-1-RND3907_1_11</name>
    <nbytes>0.000000</nbytes>
    <max_nbytes>5000000.000000</max_nbytes>
    <status>0</status>
    <upload_url>http://www.gpugrid.org/PS3GRID_cgi/file_upload_handler</upload_url>
</file>

---

FAQ's

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

Richard,
Why is it that max_nbytes only needs to be change for the _9 file, and not the others? - TIA

Because, in my experience, only one of the multiple upload files grows proportionately to the runtime of the task. In the case of the VERYLONG tasks, it's file _9 which is the one which grows - and in this case grows too much.

No harm will be done if you extend the limits on the other files as well, but in my experience doing multiple repetitive edits is when I get bored, tired - and sloppy. And I make mistakes.

Client_state.xml is a very important and sensitive file, and if you break the file 'shape' - its XML structure - in even the most trivial way, you can lose a lot of work - not just from the project you're trying to tweak. I'd always advocate making the smallest, simplest change possible - hence KISS.

My GTX 980 host is uploading the first result.
The final file size is 186.980.704 bytes.
The total processing time is 15h 39m 51s.