Please report bugs for version 5.89 here.

wowzers, takes a while to run these guys thru. I just finished my first, took almost six hours (21,240 secs)to do one decoy on my p-4 2.8ghz Win-xp box. I'm gonna have to up my preferences if they are all going to run this long!

Resid 709016

Hi: yup, they're going to take a while... when we apply filters (to allow premature exits for unpromising model), they will average 2-3 hours per model. But these are totally worth it!

wowzers, takes a while to run these guys thru. I just finished my first, took almost six hours (21,240 secs)to do one decoy on my p-4 2.8ghz Win-xp box. I'm gonna have to up my preferences if they are all going to run this long!

Resid 709016

---

Well,one of them was very quickly thrown out...
This task took too much memory and since BOINC tried second RALPH task if that one will run quickly virtual memory was insufficently small for this and task crashed.(975MB of VM)

Cruncher is notebook and I cannnot increase VM for disk is too small.

Noticed graphic bug in accepted energy bar in this work unit:
https://ralph.bakerlab.org/workunit.php?wuid=632126
It looked like that few minutes but disappeared after while.


Edit: As you can see, it appeared when 43.69% was completed.

Argh,second task crashed.Same reason.May be they should come with warning about high usage of VM...

Actually I can see high VM usage too but my computer/tasks haven't crashed because my VM is set to 1,5 GBs. At the moment mem usage is 106 MBs and VM usage 923 MBs. Same WU that I mentioned above...

Is it just me, or is the Time To Completion acting strangely?

It seems to get stuck when it says there are about 10 minutes left. Meanwhile the WU continues to run for another hour, then it all goes to 100% and it's done.

It shouldn't have anything to do with my Result Duration Correction Factor, or CPU Effiency, because I've been doing this for a while and those were calculated a long time ago for this system.

My impression is that it's a fairly recent phenomenon, maybe since 5.85 or so.

Anyone else have thoughts about this?

==Mike

---

Don't believe everything you think.

wowzers, takes a while to run these guys thru.

I've seen this also. My preferences are set to 3600 seconds, and some of these are taking between 7000-9000 seconds to generate 1 decoy.

==Mike

---

Don't believe everything you think.

That is always the case with long running models. Once they get down to 10 min the time estimate goes down the tubes. So they just keep increasing the % completed when it is refigured every 5 seconds, and that way the time keeps generally steady or falling. But it actually doesn't know how much longer it will run. So, yes, it is odd, but it is normal when the models take a long time. Especially if they take longer then your runtime preference.

---

My observation at the model end was, the % completed was steady and ETA was moving up and down, mostly up (off course).

And the mentioned graphics bug was hapening at the last few % of progress too.

Peter

Outcome Client error
Client state Downloading
https://ralph.bakerlab.org/result.php?resultid=713635

Exit status -186 (0xffffffffffffff46)

CPU time 0
stderr out

<core_client_version>5.10.28</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>native_1zpy_.psipred_ss2.gz</file_name>
<error_code>-200</error_code>
</file_xfer_error>

</message>
]]>

Validate state Invalid
Claimed credit 0
Granted credit 0
application version 5.89

Outcome Client error
Client state Downloading
https://ralph.bakerlab.org/result.php?resultid=713620

Exit status -186 (0xffffffffffffff46)

CPU time 0
stderr out

<core_client_version>5.10.28</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>native_1zpy_.fasta.gz</file_name>
<error_code>-200</error_code>
</file_xfer_error>
<file_xfer_error>
<file_name>native_1zpy_.psipred_ss2.gz</file_name>
<error_code>-200</error_code>
</file_xfer_error>

</message>
]]>

Validate state Invalid
Claimed credit 0
Granted credit 0
application version 5.89

---

Outcome Client error
Client state Downloading
https://ralph.bakerlab.org/result.php?resultid=713599

Exit status -186 (0xffffffffffffff46)

CPU time 0
stderr out

<core_client_version>5.10.28</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>native_1zpy_.fasta.gz</file_name>
<error_code>-200</error_code>
</file_xfer_error>
<file_xfer_error>
<file_name>native_1zpy_.psipred_ss2.gz</file_name>
<error_code>-200</error_code>
</file_xfer_error>

</message>
]]>

Validate state Invalid
Claimed credit 0
Granted credit 0
application version 5.89

Thanks for the screenshot -- we're looking into this, but the craziness may not be fixed for a few updates...

Noticed graphic bug in accepted energy bar in this work unit:
https://ralph.bakerlab.org/workunit.php?wuid=632126
It looked like that few minutes but disappeared after while.


Edit: As you can see, it appeared when 43.69% was completed.

---

Computational errors on two 5.89 WU's
This WU and this WU both have the same error and ran for zero time

<core_client_version>5.8.15</core_client_version>
<![CDATA[
<message>
Incorrect function. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
# cpu_run_time_pref: 21600
ERROR:: Exit from: .input_pdb.cc line: 3028

---