We just launched 400 very long WU (they will take about 24h in a 780GTX) named VERYLONG_CXCL12_confAna whose results we need as soon as possible (we are in a hurry). They come with a credit+bonus of 400K. Please, if you don't have a good graphic card, reject them. For the brave ones, take it as a challenge and see you on the performance tab ;)

Please, if you don't have a good credit card, reject them.

Nothing here ! Too bad ! Snif, snif ;)
____________
[CSF] Thomas H.V. Dupont
Founder of the team CRUNCHERS SANS FRONTIERES 2.0
www.crunchersansfrontieres

hahaha sorry. what was i thinking about...?

If it was possible to select the WU's, I would take some of the VERY LONG.

Or ... is there a way to download them ? Or will you send them with "high priority" ?

NB Will receive my 4th GTX970 tomorrow :D

Purchased only "because" of GPUGRID ;)

If it was possible to select the WU's, I would take some of the VERY LONG.

Or ... is there a way to download them ? Or will you send them with "high priority" ?

NB Will receive my 4th GTX970 tomorrow :D

Purchased only "because" of GPUGRID ;)

Just checked my tasks. No joy on the high value target.
____________

Hello Thomas,

Ou alors, il faut abandonner les UT jusqu'à ce qu'on reçoive des VeryLong MDR ?

Je transmettrai ton Bonjour ;) :)

Philippe

Received 2 : GERARD_VERYLONG_CXCL12

:D :D :D

This may be the happiest day of my life.

Received 2 : GERARD_VERYLONG_CXCL12

:D :D :D

Looking forward to compute some of them on my GTX 970 :3
Must happen ASAP! :)

Will they come Automatically? Cuz in Settings I´ve only selected Short runs :O

Hi, I've received one very long GERARD on my 560ti with 448 shaders. Does it make sense to to crunch it to the end?
Greets :-)

I got another short run-.-

Got one of these tasks on a computer with a NVIDIA GTX 680 factory OC'd video card that rarely has a processing error. I will run it unless you need the work unit assigned to another computer with a stronger/faster video card.

Saw the call for the challenge and was able to download 2 VL's while on lunch. I've got 15 hours from the time this message is being typed until my Nvidia Titan's attention can be turned to them. Excited to see if these use the full processing power of the card or if I have to run them two(or more) at a time like most GPU WU's.

Are there any settings we need to tweak to make sure we get full utilization?

These are on the, uh, normally long queue right?

Tried to opt in with my preferences, to no avail.

None here yet. Good luck and happy crunching!

These are on the, uh, normally long queue right?

Tried to opt in with my preferences, to no avail.

None here yet. Good luck and happy crunching!

We just launched 400 very long WU (they will take about 24h in a 780GTX) named VERYLONG_CXCL12_confAna whose results we need as soon as possible (we are in a hurry).

They come with a credit+bonus of 400K.

Please, if you don't have a good graphic card, reject them.

For the brave ones, take it as a challenge and see you on the performance tab ;)

Found one already downloaded and running on a GTX 670 - 10% done, and the figures suggest ~36 hours total, or mid-morning Saturday UTC for completion. Plus whatever it takes to upload the result file - most tasks generate ~5MB per hour on this card, so I'm expecting a 180 MB final upload!

I have two of these running on my GTX 680 host, it will take 28 hours and 40 minutes for the faster (1200MHz) card to finish.

Is a intel i3 with a gtx 660 fast enough?

Frustrating. I have THREE GTX 780ti SC and not even one very long WU. Aborted several long run WU to see if I could get just one and nothing.

aborted about 30 - no luck in getting the rare ones for 970.

Is GTX 970M fast enough to compute this project?
____________

Looks like 16.5 hours here! YAY!
____________
1 Corinthians 9:16 "For though I preach the gospel, I have nothing to glory of: for necessity is laid upon me; yea, woe is unto me, if I preach not the gospel!"
Ephesians 6:18-20, please ;-)
http://tbc-pa.org

Well, I don´t care if I don´t get these WU´s.. It´s ok when I can spend the little things too, it´s for Science. :)

Happy Crunching Guys! :)

It looks like my GTX 980 will finish this very long workunit in 15 hours and 40 minutes. It's 2.5 hours shorter than the estimated running time of the GTX 780Ti. These workunits has low memory controller load (29-31% on my GTX980@3.5GHz, 11% on my GTX780Ti@3.5GHz, 24% on my GTX780Ti@2.9GHz).

Is a intel i3 with a gtx 660 fast enough?

I have one on a GTX980. 43% complete after 11 hours.

Please don't cancel any more WUs to get them! I checked and they are already all taken at this point so only if they fail on some machines will they get added to the queue again. They are only a single step so they are not coming back.
I agree with Retvari that it's not a good idea to put them on the long queue. We will discuss about queues and how to organize them better.

Gerard never asked anyone to ABORT WU's to get their hands on one of these long WU's.
While you may agree with Retvari he was the first to post that he had ABORTED other WU's for no other reason than to get one of these on a particular card. His warning was a "Self Fulfilling Prophecy" and others followed.

Maybe Retvari decided that these units gave more credits and a place on the "Performance" tab and were more important than other scientists WU's. In addition, he might of thought he deserved more of them than anyone else.

Started the VL WU's early this morning while grabbing a cup of coffee. One WU only used around 60% of the Titan(May have misread, it was early :)). Currently running them concurrently and achieved 75-80 percent utilization.

Boinc is estimating 7.5 hours. Will check during lunch and see what progress is made in around 5 hrs.

... so I'm expecting a 180 MB final upload!

Fortunately, Retvari's GTX 980 mine-canary should finish in a couple of hours, and the rest of us tortoises will find out whether the hare has crashed and burned - or not.

Please don't cancel any more WUs to get them! I checked and they are already all taken at this point so only if they fail on some machines will they get added to the queue again. They are only a single step so they are not coming back.
I agree with Retvari that it's not a good idea to put them on the long queue. We will discuss about queues and how to organize them better.

Gerard never asked anyone to ABORT WU's to get their hands on one of these long WU's.
While you may agree with Retvari he was the first to post that he had ABORTED other WU's for no other reason than to get one of these on a particular card. His warning was a "Self Fulfilling Prophecy" and others followed.
Maybe Retvari decided that these units gave more credits and a place on the "Performance" tab and were more important than other scientists WU's. In addition, he might of thought he deserved more of them than anyone else.

Good points, both of you! (Richard Haselgrove & Dayle)

My GTX780Ti has 55 minutes left, so we have to act fast.
The 4x14-GERARD_VERYLONG_CXCL12_confAna-0-1-RND7430_0_9 file on that host has grown to 177639400 bytes, which is larger than the specified size in the client_state.xml file, but if you look for the previous file section, it's upload size is doubled. So I think that the wrong file size is doubled by accident.

It looks like the 970 PNY will take about 30 hours to complete these WU's while the 970 Gaming G1 will need about 24 hours.

(The PNY are connected to an old PCI E 2.0 MB ... :/)

Good points, both of you! (Richard Haselgrove & Dayle)

My GTX780Ti has 55 minutes left, so we have to act fast.
The 4x14-GERARD_VERYLONG_CXCL12_confAna-0-1-RND7430_0_9 file on that host has grown to 177639400 bytes, which is larger than the specified size in the client_state.xml file, but if you look for the previous file section, it's upload size is doubled. So I think that the wrong file size is doubled by accident.

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).

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).

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.

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.

This is deadly serious! Every workunit will fail to upload, so the whole "challenge" will come to naught without user intervention.
Those who can't edit their client_state.xml should abort these workunits immediately.
Also, if you've received a fresh one of them, you should edit the client_state.xml again!

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:

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

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

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

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

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

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.

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.

Edit: Hmm from this example above it looks like some WUs may have _1_9 instead of the _0_9 that all of mine had:

<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>

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.

The BOINC administrator just raised the upload limit to 512 Mb, please let us know if you can upload the WU now.

The BOINC administrator just raised the upload limit to 512 Mb, please let us know if you can upload the WU now.

The upload of the first result is finished.
Here are the details: 3x17-GERARD_VERYLONG_CXCL12_confAna-0-1-RND9026_1

The BOINC administrator just raised the upload limit to 512 Mb, please let us know if you can upload the WU now.

It should be fine for newly created WUs, but I'm not sure whether the change will propagate to automatically-generated replacements for tasks which fail - we'll need to keep an eye on those.

It certainly won't be passed to tasks which are already 'out in the field' - on volunteers' computers. They will have to be modified manually, or allowed to fail.

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.

The BOINC administrator just raised the upload limit to 512 Mb, please let us know if you can upload the WU now.

It should be fine for newly created WUs, but I'm not sure whether the change will propagate to automatically-generated replacements for tasks which fail - we'll need to keep an eye on those.

It certainly won't be passed to tasks which are already 'out in the field' - on volunteers' computers. They will have to be modified manually, or allowed to fail.

Even if you "update" the project ?

Congratulations on the home run - and thanks for the confirmation that the file edit is effective.

Congratulations on the home run - and thanks for the confirmation that the file edit is effective.

Thank you!
We had similar upload size problems before, and the solution was the same back then.

My second very long workunit is uploading.
7x6-GERARD_VERYLONG_CXCL12_confAna-0-1-RND0829_0

I'm glad I checked this thread again. Two of my clients have one of the very long WUs. I implemented the fix as described by Richard. I'll keep an eye on it and check the status on completion.
http://www.gpugrid.net/result.php?resultid=13737049 (GTX 770)
http://www.gpugrid.net/result.php?resultid=13737185 (GTX 670)
____________

Thanks for the detailed guidance Richard and Retvari!

I just got home from work and checked this thread. My WU was 90%+ done so just in time.

4x6-GERARD_VERYLONG_CXCL12_confAna-0-1-RND1754_0_0 working now. It started out and continued to count down about 18.5 hours till completion, then at 48.8% finished and about 13 hours is jumped to 13.5 hours left. hah! Anyway, with just around 10 hours showing left I am changing the xml according to Richard's instructions. Only have one since I only have the one machine I run longs on. Good thing it has the 3 780's in it. I'll keep an eye out to see if I get any more in the near future also. Right now I have 3 queued and 3 working and only 1 of these.
____________
1 Corinthians 9:16 "For though I preach the gospel, I have nothing to glory of: for necessity is laid upon me; yea, woe is unto me, if I preach not the gospel!"
Ephesians 6:18-20, please ;-)
http://tbc-pa.org

We just launched 400 very long WU (they will take about 24h in a 780GTX) named VERYLONG_CXCL12_confAna whose results we need as soon as possible (we are in a hurry).

I've got two of them on my GTX 780Ti host.
According to my linear approximation made at 12.3% progress, the total computing time will be about 18 hours and 15 minutes.

They come with a credit+bonus of 400K.

That's nice.

Please, if you don't have a good graphic card, reject them.

That's an inappropriate way to arrange such batches.
You should set up a third queue for these purposes.
I couldn't receive one of these workunits on my GTX980 host. I'm sure I'm not alone with that.
EDIT: I had to abort 10 other workunits to receive one of these on my GTX980 host.
That's why your method is dangerous: it propagates failed workunits (by encouraging user intervention)

For the brave ones, take it as a challenge and see you on the performance tab ;)

Challenge accepted. :)

Finally got one but on my GTX560ti which I aborted but nothing for my GTX970

Need to get a better system, no doubt about that.

Absolutely agree that this is an inappropriate way to handle these large work units. Another "very long" queue like Retvari says or have the server automatically figure out what computers should get them based on the installed graphics cards.

I see that after the first VERYLONG units errored out, it has been posted that it was necessary to edit the xml before finishing the task.

When I read that, it had taken my GTX 770 31 hours 24 minutes to complete the task.
Not amused to see the log:

24/01/2015 08:46:57 | GPUGRID | Output file 6x13-GERARD_VERYLONG_CXCL12_confAna-0-1-RND0906_0_9 for task 6x13-GERARD_VERYLONG_CXCL12_confAna-0-1-RND0906_0 exceeds size limit.
24/01/2015 08:46:57 | GPUGRID | File size: 186797160.000000 bytes. Limit: 128000000.000000 bytes

Hello.

I got the same unhappy result.

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

It took my Titan black roughly 25 hours to complete the task.

Next time, please be more careful what you prepare for cranching. I am very keen to help, but this is a waste of time that could had been used for other tasks.

Hello.

I got the same unhappy result.

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

It took my Titan black roughly 25 hours to complete the task.

Next time, please be more careful what you prepare for cranching. I am very keen to help, but this is a waste of time that could had been used for other tasks.
____________

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

Hi,

I got an upload error for one of long running tasks. Any Boinc infrastructure limit reached?


Task:
10583226 3x24-GERARD_VERYLONG_CXCL12_confAna-0-1-RND1384_0

Error Msg:
12:58:29 (8716): called boinc_finish

</stderr_txt>
<message>
upload failure: <file_xfer_error>
<file_name>3x24-GERARD_VERYLONG_CXCL12_confAna-0-1-RND1384_0_9</file_name>
<error_code>-131 (file size too big)</error_code>
</file_xfer_error>

</message>

Georg

Hi,

I got an upload error for one of long running tasks. Any Boinc infrastructure limit reached?

Errors can happen, so no hard feeling to the research project.
Unfortunately I was away yesterday when Zoltan mentioned the issue and together with Richard, a solution was given.

Mine finished in error before I could intervene, thus about 24hours wasted on my two fastest cards.

Edit: Repair the WU's Gerard, issue them again and I will let them crunch again on my rigs.
____________
Greetings from TJ

mine also finished with result upload error:

upload failure: <file_xfer_error>
<file_name>3x1-GERARD_VERYLONG_CXCL12_confAna-0-1-RND5972_0_9</file_name>
<error_code>-131 (file size too big)</error_code>
</file_xfer_error>

For those that can't be bothered to read through the topic...Your fix for the "old" WU's.

http://www.gpugrid.net/forum_thread.php?id=3988&nowrap=true#39636

Crunch on! Thanks again to the awesome people that gave their time and energy for solving this issue in a timely manner! :D

http://www.gpugrid.net/forum_thread.php?id=3988&nowrap=true#39636

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).

Provided the _1_9 file has the increased <max_nbytes> 512,000,000 you should be fine (_1 in this case, because it's a resent task).

Yes, it is the _1_9 file.
<name>7x27-GERARD_VERYLONG_CXCL12_confAna-0-1-RND7320_1_9</name>

I don't know if a GTX 660 Ti is really worth doing it on, but since it started and a lot of others have errored out, I figured it would be the fastest way to get a result back.

I don't know if a GTX 660 Ti is really worth doing it on,

Quite true, but we don't have much flexibility here. Once they start, we may not catch them for a few hours as we both know. Then we have to decide whether to keep going or not. With the lack of any guidance, it is anyone's guess. I am sure they will think of a better way to do it next time.

Just got another one, but this time I could shunt it off to my one 670 card (thanks flashhawk!). We'll see how that goes.

I've received another one of these, and I confirm that the upload size has been doubled, so this problem is fixed by now.

I got 2 of the very long wus and computed 60 hours total. After reaching 99 % each wu aborted with an computing error.
---> 0 (Zero) Points for 60 hours computing
Thank you...

I got 2 of the very long wus and computed 60 hours total. After reaching 99 % each wu aborted with an computing error.
---> 0 (Zero) Points for 60 hours computing
Thank you...

I got 2 of the very long wus and computed 60 hours total. After reaching 99 % each wu aborted with an computing error.
---> 0 (Zero) Points for 60 hours computing
Thank you...

That is unfortunate. Please post the error message.

I have just noticed that my 750 Ti got one of these.
It's at 92% now and total time seems to be 44 hours. Not bad for such a small and low power GPU...