Hi gang,

The testing for the CPU application is over and these are the first production WUs.

In this project we are studying the PI3Kalpha, a mutation of which is implicated in tumor formation. You can read more about it, and see the structure, here: http://www.rcsb.org/pdb/explore.do?structureId=3HHM

Over the course of this project we will be testing some 22 million commercially-available drug-like molecules, drawn from the ZINC database http://zinc.docking.org/, to find compounds which are predicted to bind strongly to the protein in a way which will inhibit its function.

Once we have screen the whole database, we will take the best hits and test them for efficacy in a series of in vitro experiments. Hopefully we will find inhibitory compounds which can then serve as the basis for future drug development.

Matt

Thanks for the information, looks exciting!

Can you please have a look at this host's tasks (my wife's laptop) -- the tasks seem to be erroring out.
http://www.gpugrid.net/results.php?hostid=85944

Exit status -226 (0xffffffffffffff1e) ERR_TOO_MANY_EXITS

... near step:
# (BOINC) Mapping [ligand.pdbqt]->[ligand.pdbqt]
17:11:39 (1732): BOINC client no longer exists - exiting
17:11:39 (1732): timer handler: client dead, exiting

I have set my preferences (all gone when saving changed one), to do these CPU tasks as well.
However as these run quite fast, the remaining estimation of the GPU tasks is wrong. BOINC Manager now things my 770 and 780Ti can do a LR in 38 minutes, would be amazingly awesome though :)

---

Greetings from TJ

Watching more closely I see the following as well. Only about 6% is done from the CPU WU (in 15 minutes) and 5 minutes remain. The at about 8.5% done, estimation time is zero and within a few seconds later, the WU finishes to 100% and is uploaded and reported home, without error. Strange behavior.

---

Greetings from TJ

On Linux the progress just jumps from 0% to 100%, runtime varies from around 9min to 13min (for me). The estimated runtime for these CPU workunits has dropped from several hours to just over 2h. The GPUGrid Long GPU tasks estimates have also dropped to just over 2h. The estimated computation size is the same as the Long GPU tasks!

---

FAQ's

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

On Linux the progress just jumps from 0% to 100%, runtime varies from around 9min to 13min (for me). The estimated runtime for these CPU workunits has dropped from several hours to just over 2h. The GPUGrid Long GPU tasks estimates have also dropped to just over 2h. The estimated computation size is the same as the Long GPU tasks!

Thanks for conformation skgiven. Proves my eyes are still okay :)

---

Greetings from TJ

Can you please have a look at this host's tasks (my wife's laptop) -- the tasks seem to be erroring out.
http://www.gpugrid.net/results.php?hostid=85944

Exit status -226 (0xffffffffffffff1e) ERR_TOO_MANY_EXITS

... near step:
# (BOINC) Mapping [ligand.pdbqt]->[ligand.pdbqt]
17:11:39 (1732): BOINC client no longer exists - exiting
17:11:39 (1732): timer handler: client dead, exiting

MJH:
All of the GPUGrid CPU tasks are erroring out, on these 2 hosts I manage:
http://www.gpugrid.net/results.php?hostid=137361
http://www.gpugrid.net/results.php?hostid=85944
... Do you have any idea what is happening with the repeated exits near the step mentioned above?
I'll try unattaching and reattaching the project, but... it'd be nice if you might mention if you know what might be causing this problem on 2 separate machines. Edit: Project unattach/reattach and resets.. did not help.

Please help!

I'm super excited about the possibility about having these non-GPU computers do work for your project, for the first time ever, but...

They need your help!

The ones I spot-checked all ran for 11 seconds, failed with that 'client dead' message, and then seem to have re-tried to process with the same input file.

You'll remember my recent email exchange with David A on the subject of 'ERR_TOO_MANY_EXITS', of course?

What does the BOINC Message (event) log have to say about all those client deaths?

I doubt the Event Log will say much, but I'll try to monitor it sometime.
From what I can see, this is an application error that GPUGrid (MJH) needs to fix.
Each "attempt" is a waste of 10 CPU seconds, and you can see below just how many times each task is attempted before failure.

It is literally wasting several minutes of CPU, for each task, only to fail.

MJH: I hope you can solve this one, please!

Looking at the timestamps below, I see:
01:22:53
...
01:38:25

That's 16 minutes of wasted CPU, and the log file wasn't even captured entirely, as the introduction was truncated. So.... we're looking at 20+ minutes of wasted CPU per task.

Please fix!

Stderr output

<core_client_version>7.2.42</core_client_version>
<![CDATA[
<message>
too many exit(0)s
</message>
<stderr_txt>
7236): BOINC client no longer exists - exiting
01:22:53 (7236): timer handler: client dead, exiting
# (BOINC) Mapping [ligand.tar]->[ligand.tar] 
# (BOINC) Mapping [results.tar]->[../../projects/www.gpugrid.net/2784-DOCK_LAB_MJHARVEY_18211_3HHM2_ZINC9-0-1-RND7172_0_0] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [flexible.pdbqt]->[flexible.pdbqt] 
nextfile: reading [in]
[.]
[..]
[ligand-9243.pdbqt]
NEXTFILE : [out] [ligand-9243.pdbqt] 
copy [in/ligand-9243.pdbqt]->[ligand.pdbqt]
# (BOINC) Mapping [input.dat]->[input.dat] 
# (BOINC) Mapping [progress.log]->[progress.log] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [ligand.pdbqt]->[ligand.pdbqt] 
01:23:03 (216): BOINC client no longer exists - exiting
01:23:03 (216): timer handler: client dead, exiting
# (BOINC) Mapping [ligand.tar]->[ligand.tar] 
# (BOINC) Mapping [results.tar]->[../../projects/www.gpugrid.net/2784-DOCK_LAB_MJHARVEY_18211_3HHM2_ZINC9-0-1-RND7172_0_0] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [flexible.pdbqt]->[flexible.pdbqt] 
nextfile: reading [in]
[.]
[..]
[ligand-9243.pdbqt]
NEXTFILE : [out] [ligand-9243.pdbqt] 
copy [in/ligand-9243.pdbqt]->[ligand.pdbqt]
# (BOINC) Mapping [input.dat]->[input.dat] 
# (BOINC) Mapping [progress.log]->[progress.log] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [ligand.pdbqt]->[ligand.pdbqt] 
01:23:14 (7032): BOINC client no longer exists - exiting
01:23:14 (7032): timer handler: client dead, exiting
# (BOINC) Mapping [ligand.tar]->[ligand.tar] 
# (BOINC) Mapping [results.tar]->[../../projects/www.gpugrid.net/2784-DOCK_LAB_MJHARVEY_18211_3HHM2_ZINC9-0-1-RND7172_0_0] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [flexible.pdbqt]->[flexible.pdbqt] 
nextfile: reading [in]
[.]
[..]
[ligand-9243.pdbqt]
NEXTFILE : [out] [ligand-9243.pdbqt] 
copy [in/ligand-9243.pdbqt]->[ligand.pdbqt]
# (BOINC) Mapping [input.dat]->[input.dat] 
# (BOINC) Mapping [progress.log]->[progress.log] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [ligand.pdbqt]->[ligand.pdbqt] 
01:23:25 (7480): BOINC client no longer exists - exiting
01:23:25 (7480): timer handler: client dead, exiting
# (BOINC) Mapping [ligand.tar]->[ligand.tar] 
# (BOINC) Mapping [results.tar]->[../../projects/www.gpugrid.net/2784-DOCK_LAB_MJHARVEY_18211_3HHM2_ZINC9-0-1-RND7172_0_0] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [flexible.pdbqt]->[flexible.pdbqt] 
nextfile: reading [in]
[.]
[..]


.....

[.]
[..]
[ligand-9243.pdbqt]
NEXTFILE : [out] [ligand-9243.pdbqt] 
copy [in/ligand-9243.pdbqt]->[ligand.pdbqt]
# (BOINC) Mapping [input.dat]->[input.dat] 
# (BOINC) Mapping [progress.log]->[progress.log] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [ligand.pdbqt]->[ligand.pdbqt] 
01:38:15 (6340): BOINC client no longer exists - exiting
01:38:15 (6340): timer handler: client dead, exiting
# (BOINC) Mapping [ligand.tar]->[ligand.tar] 
# (BOINC) Mapping [results.tar]->[../../projects/www.gpugrid.net/2784-DOCK_LAB_MJHARVEY_18211_3HHM2_ZINC9-0-1-RND7172_0_0] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [flexible.pdbqt]->[flexible.pdbqt] 
nextfile: reading [in]
[.]
[..]
[ligand-9243.pdbqt]
NEXTFILE : [out] [ligand-9243.pdbqt] 
copy [in/ligand-9243.pdbqt]->[ligand.pdbqt]
# (BOINC) Mapping [input.dat]->[input.dat] 
# (BOINC) Mapping [progress.log]->[progress.log] 
# (BOINC) Mapping [protein.pdbqt]->[protein.pdbqt] 
# (BOINC) Mapping [ligand.pdbqt]->[ligand.pdbqt] 
01:38:25 (7780): BOINC client no longer exists - exiting
01:38:25 (7780): timer handler: client dead, exiting

</stderr_txt>
]]>

Since we seem to have plenty of work available, would you please consider increasing the limit per host for cpu work?

I get max. 16 workunit for an i7 with 8 threads. Since they need less then 30 min. on average, that's hardly one hour worth of work. A cache of at least half a day would be nice (that's an approx. limit of 24 per thread in my case). I'm not always on with a fast connection. ;-)

It doesn't seem to be universal. Some of the ones which fail go on to crash on every machine which tries them, but others run successfully.

Look at WU 5573123: the first failure is from Jacob's list, but the task ran successfully on a machine with comparable specifications (i7, Windows 8.1 64-bit, BOINC v7.2.42).

I'm trying to reproduce on host 93580, but so far the application is working properly (45% in 25 minutes, moving on from file to file as each segment is completed).

Since we seem to have plenty of work available, would you please consider increasing the limit per host for cpu work?

Looking into that now..

Matt

Since we seem to have plenty of work available, would you please consider increasing the limit per host for cpu work?

I get max. 16 workunit for an i7 with 8 threads. Since they need less then 30 min. on average, that's hardly one hour worth of work. A cache of at least half a day would be nice (that's an approx. limit of 24 per thread in my case). I'm not always on with a fast connection. ;-)

+1.....

Since we seem to have plenty of work available, would you please consider increasing the limit per host for cpu work?

I get max. 16 workunit for an i7 with 8 threads. Since they need less then 30 min. on average, that's hardly one hour worth of work. A cache of at least half a day would be nice (that's an approx. limit of 24 per thread in my case). I'm not always on with a fast connection. ;-)

I should have increased it now.

gianni

Since we seem to have plenty of work available, would you please consider increasing the limit per host for cpu work?

I get max. 16 workunit for an i7 with 8 threads. Since they need less then 30 min. on average, that's hardly one hour worth of work. A cache of at least half a day would be nice (that's an approx. limit of 24 per thread in my case). I'm not always on with a fast connection. ;-)

I should have increased it now.

gianni

............... great - currently I have 36 CPU & 2 GPU in my queue. Thanks

Excellent. We ought to see a big improvement in throughput now!

Matt

Any progress on solving the issue I'm seeing on multiple machines?

These WUs have some weird behavior. While they run perfectly fine, their Progress jumps abruptly from ~5% to 100%. This not only means that their estimated processing work is grossly miscalculated, it also messes up BOINC's estimations. I discovered yesterday evening that I had downloaded a GERARD while the currently processing NATHAN had several more hours of work ahead. Looking at the BOINC manager, the cause for this was evident: while the GPU WU needed several more hours on my GTX 650Ti, BOINC thought it just needed 30 more minutes! Just like that, I would have lost the credit bonus, because BOINC messed up its estimations!

I assert that this is due to these CPU WUs and their weird Progress "jump". I've been crunching GPUGRID together with WCG on the same host for a year now and this had never happened. It started happening as soon as I suspended WCG and enabled CPU apps on GPUGRID.

To give you a concrete example, this WU took just over 10.5 minutes, but BOINC estimated it to need more than 4.5 hours! Doesn't this affect estimations of future WUs?

---

These WUs have some weird behavior. While they run perfectly fine, their Progress jumps abruptly from ~5% to 100%. This not only means that their estimated processing work is grossly miscalculated, it also messes up BOINC's estimations. I discovered yesterday evening that I had downloaded a GERARD while the currently processing NATHAN had several more hours of work ahead. Looking at the BOINC manager, the cause for this was evident: while the GPU WU needed several more hours on my GTX 650Ti, BOINC thought it just needed 30 more minutes! Just like that, I would have lost the credit bonus, because BOINC messed up its estimations!

I assert that this is due to these CPU WUs and their weird Progress "jump". I've been crunching GPUGRID together with WCG on the same host for a year now and this had never happened. It started happening as soon as I suspended WCG and enabled CPU apps on GPUGRID.

To give you a concrete example, this WU took just over 10.5 minutes, but BOINC estimated it to need more than 4.5 hours! Doesn't this affect estimations of future WUs?

That's exactly what I also found out yesterday and continues it..
I also had problems for a while when I enabled cpu GPUGRID tasks.

Now I have to just few Nathan estimeted whose requires 16 hours to 680gtx NV.....
Yesterday I've even some few extra long tasks, you can see them in my tasks..
I2010R1-SDOERR_BARNA-3-4-RND4946_0 6406280 62,142.59 Gpu time 21,988.47 cpu time..WOW
We will be just happy if they'll catch solve these emerging issues..)))