Posts by Mike Gelvin

1) Message boards : RALPH@home bug list : minirosetta_graphics_1.09 identified as a possible virus (Message 3816)
Posted 10 Mar 2008 by Mike Gelvin
Post:
NOD32 declared http://ralph.bakerlab.org/download/minirosetta_graphics_1.09_windows_intelx86.exe to be a possible varient of variant of Win32/Statik

This is the same issue I saw with 1.05 and 1.08 main apps. Whatever the common code is between the main app and now the "graphics" part is causing major problems. Please fix this.
2) Message boards : RALPH@home bug list : Rosetta Mini 1.08 identified as a possible virus (Message 3778)
Posted 21 Feb 2008 by Mike Gelvin
Post:
I use NOD 32 and Mini 1.08 has been identified as a possible virus, along with 1.07 and 1.05. Please fix this.
3) Message boards : RALPH@home bug list : Rosetta Mini 1.05 identified as a possible virus (Message 3698)
Posted 9 Feb 2008 by Mike Gelvin
Post:
Time Module Object Name Threat
1/31/2008 22:49:40 PM IMON file http://ralph.bakerlab.org/download/minirosetta_1.05_windows_intelx86.exe probably a variant of Win32/Statik application


and more recently:

Time Module Object Name Threat
2/8/2008 23:18:47 PM IMON file http://srv1.bakerlab.org/rosetta/download/minirosetta_1.07_windows_intelx86.exe probably a variant of Win32/Statik application

4) Message boards : RALPH@home bug list : Rosetta Mini 1.05 identified as a possible virus (Message 3683)
Posted 1 Feb 2008 by Mike Gelvin
Post:
I use NOD32 as a virus scanner and it has identified Mini 1.05 as a possible variant of the Win32/Statik virus. Has anyone else had any trouble with this?
5) Message boards : RALPH@home bug list : Bug reports for 5.60-5.62 (Message 3012)
Posted 26 Apr 2007 by Mike Gelvin
Post:
First workunit I got promptly crashed:

http://ralph.bakerlab.org/result.php?resultid=496686

<core_client_version>5.8.15</core_client_version>
<![CDATA[
<message>
Incorrect function. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
ERROR:: Unable to obtain total_residue & sequence.
start pdb file must be provided.
ERROR:: Exit from: .input_pdb.cc line: 2944
# cpu_run_time_pref: 3600

</stderr_txt>
]]>




with 0 CPU time.... this does not bode well...

6) Message boards : RALPH@home bug list : Bug reports for Ralph 5.30 and 5.31 and 5.32 (Message 2362)
Posted 9 Oct 2006 by Mike Gelvin
Post:
A -161 error
http://ralph.bakerlab.org/workunit.php?wuid=248602
7) Message boards : Current tests : New crediting system (Message 2118)
Posted 16 Aug 2006 by Mike Gelvin
Post:
As I understand it, a fixed credit ratio shall be granted for completed decoys. And this ratio shall be determined from the type of work unit. If this is so, and it is nearing roll out time, then these ratios must have been already determined, or are being determined. If this is so, could those ratios be put in place here to allow us to experience the full flavor of the new system?
8) Message boards : RALPH@home bug list : Bug reports for Ralph 5.20 (Message 1756)
Posted 3 Jun 2006 by Mike Gelvin
Post:
I ran 3 work units.

Two actually completed but I suspect the "dormant" bug is still present as this first work (149120) unit completed in EXACTLY 1 hour with 36 min of CPU time, and this other one (149885) completed in EXACTLY 2 hours with 81 min of CPU time.

The third (149194) errored out with:
Unrecoverable error for result t296__CASP7_ABINITIO_SAVE_ALL_OUT_hom013__614_2_1 (One or more arguments are invalid (0x80000003) - exit code -2147483645 (0x80000003))

The upload indicated a watchdog shut down.

Mike
9) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1747)
Posted 2 Jun 2006 by Mike Gelvin
Post:
I ran into one of those 'stuck' abrelax wu's overnite:
resid 144202
running ralph 5.19 on my P-M laptop. It showed 100% done at 3:14:58 CPU time, but no activity, screensaver wouldn't come up (blank area only), task manager showed all cycles going to System Idle Process. Suspended acty and re-started Boinc, no-joy. Closed BM and re-started machine, brought it back up, no-joy. Aborted the WU and BM went right back to work. Didn't want to wait ?16hrs? (4x4) to see if it would somehow wake-up and finish on its own!


My experiance with this is that it will always finish within one hour of getting into this mode. If you look at the messages, and see when the WU started, take the minutes and seconds portion (like 5:10:20). When your PC time (wall time) reaches the same minutes and seconds (like 7:10:20), the work unit will complete. I know its weird, but thats what I am seeing.

Mike
10) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1737)
Posted 1 Jun 2006 by Mike Gelvin
Post:
I confirm earlier reported error out condition:

Incorrect function. (0x1) - exit code 1 (0x1); ERROR:: Exit at: .barcode_classes.cc line:500

in these two work units:

146315
145904

AND

after observing several more dormant cases, I conclude that the application goes dormant until the wall clock time reaches an even hour after the app starts before terminating "normally". This time is TO THE SECOND. This is independent of the CPU time taken.
11) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1724)
Posted 31 May 2006 by Mike Gelvin
Post:
This version works without problems on x64.

Work tasks : OK
Graphics : OK
This time I had a work unit that ran for 59 min 35 seconds... then went dormant for 60 min 25 seconds. Total was 2 hrs instead of 1.

Are your workunits CASP7? If so, it's natural to delay to finish.


Whole different issue, my CPU utilization dropped to 0. In this specific case, it remained at 0 for 60 min 25 sec. This is a waste of CPU cycles.
All work units are CASP7 as far as I know.

Moderator9 has mentioned in the post, http://ralph.bakerlab.org/forum_thread.php?id=209#1654
d287__CASP7_ABRELAX_521_7

has been running for 6 hours and shows only 1.044% progress. This is running on a Mac.


Let it run. It is a test Work Unit for CASP7. It is probably just a large Work Unit. Do not be surprised if it suddenly jumps to 100% at the end of the first model. Do not stop Boinc Or Rosetta or it will start over at 0%.

If it gets to the place where is has run longer that about 5 times the setting for "Time" in your preferences, it will either be stopped by the "Watchdog" or you might want to consider aborting it manually at that time.

Keep us posted.


If your units aren't CASP7 ones, it might be an error, I think.

12) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1722)
Posted 31 May 2006 by Mike Gelvin
Post:
Had an occasion where a work unit was showing at the end 100% complete but was not using any CPU time. I investigated and indeed the Idle Task was running at 99%+ while the 5.19 work unit was apparently idle. This lasted for at least 2 minutes, but might have been up to 2 hours before I saw it as that's how much time the Idle task has accumulated. Without intervention, the work unit completed and was reported normally. Not sure what this means, I'll keep an eye out for a similar occurrence.


As I was typing this, another work unit has gotten into this mode. Showing 100% complete and not using any CPU time.


It completed after being dormant for 18 minutes. I'll watch for another.


The very next work unit also showed 100% with no CPU time after about 40 minutes of run time. It stayed dormant for 20 minutes, then completed and reported.


For the next two work units. Run 35 minutes, dormant for 24. Run 51 minutes, dormant for 9.

The pattern seems to be that the work unit will go dormant after completion until one full hour has elapsed.

Note: this is in the account file for Ralph: <cpu_run_time>0</cpu_run_time>



This time I had a work unit that ran for 59 min 35 seconds... then went dormant for 60 min 25 seconds. Total was 2 hrs instead of 1.
13) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1721)
Posted 30 May 2006 by Mike Gelvin
Post:
Had an occasion where a work unit was showing at the end 100% complete but was not using any CPU time. I investigated and indeed the Idle Task was running at 99%+ while the 5.19 work unit was apparently idle. This lasted for at least 2 minutes, but might have been up to 2 hours before I saw it as that's how much time the Idle task has accumulated. Without intervention, the work unit completed and was reported normally. Not sure what this means, I'll keep an eye out for a similar occurrence.


As I was typing this, another work unit has gotten into this mode. Showing 100% complete and not using any CPU time.


It completed after being dormant for 18 minutes. I'll watch for another.


The very next work unit also showed 100% with no CPU time after about 40 minutes of run time. It stayed dormant for 20 minutes, then completed and reported.


For the next two work units. Run 35 minutes, dormant for 24. Run 51 minutes, dormant for 9.

The pattern seems to be that the work unit will go dormant after completion until one full hour has elapsed.

Note: this is in the account file for Ralph: <cpu_run_time>0</cpu_run_time>

14) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1720)
Posted 30 May 2006 by Mike Gelvin
Post:
Had an occasion where a work unit was showing at the end 100% complete but was not using any CPU time. I investigated and indeed the Idle Task was running at 99%+ while the 5.19 work unit was apparently idle. This lasted for at least 2 minutes, but might have been up to 2 hours before I saw it as that's how much time the Idle task has accumulated. Without intervention, the work unit completed and was reported normally. Not sure what this means, I'll keep an eye out for a similar occurrence.


As I was typing this, another work unit has gotten into this mode. Showing 100% complete and not using any CPU time.


It completed after being dormant for 18 minutes. I'll watch for another.


The very next work unit also showed 100% with no CPU time after about 40 minutes of run time. It stayed dormant for 20 minutes, then completed and reported.
15) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1719)
Posted 30 May 2006 by Mike Gelvin
Post:
Had an occasion where a work unit was showing at the end 100% complete but was not using any CPU time. I investigated and indeed the Idle Task was running at 99%+ while the 5.19 work unit was apparently idle. This lasted for at least 2 minutes, but might have been up to 2 hours before I saw it as that's how much time the Idle task has accumulated. Without intervention, the work unit completed and was reported normally. Not sure what this means, I'll keep an eye out for a similar occurrence.


As I was typing this, another work unit has gotten into this mode. Showing 100% complete and not using any CPU time.


It completed after being dormant for 18 minutes. I'll watch for another.
16) Message boards : RALPH@home bug list : Bug reports for Ralph 5.17-5.19 (Message 1718)
Posted 30 May 2006 by Mike Gelvin
Post:
Had an occasion where a work unit was showing at the end 100% complete but was not using any CPU time. I investigated and indeed the Idle Task was running at 99%+ while the 5.19 work unit was apparently idle. This lasted for at least 2 minutes, but might have been up to 2 hours before I saw it as that's how much time the Idle task has accumulated. Without intervention, the work unit completed and was reported normally. Not sure what this means, I'll keep an eye out for a similar occurrence.


As I was typing this, another work unit has gotten into this mode. Showing 100% complete and not using any CPU time.
17) Message boards : Number crunching : 5.14 option? (Message 1699)
Posted 26 May 2006 by Mike Gelvin
Post:
Debugging is optional... okay... how? Is it on, is it off? How do we test it?


See this post Item 2.


Item 2 wasn't very helpful?
18) Message boards : Number crunching : 5.14 option? (Message 1603)
Posted 12 May 2006 by Mike Gelvin
Post:
Debugging is optional... okay... how? Is it on, is it off? How do we test it?
19) Message boards : RALPH@home bug list : Bug reports for Ralph 5.05 and higher (Message 1487)
Posted 5 May 2006 by Mike Gelvin
Post:
So the short of this is, if the workunit is simply running uninterrupted, it could run forever, or until it hits the Max time setting. This is the risk of running a single project setup. If you don't see movement in the graphic, try suspending the Work unit and letting the system run a different one for 5 min. Then restart the first Work unit again for 5 min. Repeat this process 4 -5 times and it should abort the workunit if it was stuck. If it is not stuck it should let it keep running. Either that or we have a watchdog bug.



Does the "Max time" get checked even if the app is not swapped out? That could be it, as my computer was running in EDF mode, hence it NEVER got swapped.

May I suggest that these items, (flavors of the watchdogs) get checked whenever BOINC requests a checkpoint? I understand this is every hour or so. I realize that Rosetta doesn’t perform the checkpoint, but it could process watchdog duties.


20) Message boards : RALPH@home bug list : Bug reports for Ralph 5.05 and higher (Message 1484)
Posted 5 May 2006 by Mike Gelvin
Post:
[This computer is headless. Remote access only. Hence no screensaver.

Mike, I use VNC to see the graphics on my remote monitorless, keyboardless, and mouseless puter. I click on the WU from the task tab and then view graphics. No screensaver here either. If it's a service install your hosed.

tony


It is a service install. I forgot about the "View Graphics button" I do VN into this computer. OK... 1.041% complete after 40 hours. Stage Full atom relax, Mode 1, Step 100, Accepted RMSD 50.36, Accepted Energy -19.40622 whatever this all means.


Starting and stopping did indeed reset the time to 0 (I had to reboot for other reasons). I am going to allow it to build back up... at over 24 I will report back. Its the Max Time Setting (24 hrs) that appears to not be working.


Next 20



©2024 University of Washington
http://www.bakerlab.org