Posts by Keith T.

21) Message boards : Number crunching : Problems with Minirosetta v1.54 (Message 59651) Posted 18 Feb 2009 by Keith T. Post: At least 3 of my recent tasks have resulted in Validate errors. http://boinc.bakerlab.org/rosetta/result.php?resultid=227721905 http://boinc.bakerlab.org/rosetta/result.php?resultid=227934901 http://boinc.bakerlab.org/rosetta/result.php?resultid=227919237 Please could someone in authority explain why there have been so many of these recently. I currently have Rosetta set to "No New Tasks", partly because of these. I am still accepting work from RALPH. Keith
22) Message boards : Number crunching : SERVER PROBLEMS. (Message 57720) Posted 8 Dec 2008 by Keith T. Post: Looks like my guess was right. The master_boinc.bakerlab.org_rosetta.xml has been updated without the [SPACE] and I have now been able to connect and report results. Thanks to the admin that corrected this. Keith.
23) Message boards : Number crunching : SERVER PROBLEMS. (Message 57717) Posted 8 Dec 2008 by Keith T. Post: Hello Keith T. You might try the next link which brings you to a post from Evan at the Server Problem? - thread: You can fix it yourself. Good luck, Path7. I tried just editing client_state to put the new url in still got the error. I will try editing the client_state_prev as well later, but I think I have spotted the error in the master file. There is a [SPACE] in the file where I think there should not be. <scheduler>http://srv4.bakerlab.org/rosetta_cgi/cgi </scheduler> <scheduler>http://srv4.bakerlab.org/rosetta_cgi/cgi</scheduler>
24) Message boards : Number crunching : SERVER PROBLEMS. (Message 57705) Posted 8 Dec 2008 by Keith T. Post: I have also been unable to report completed tasks for the last week. I now have 2 tasks "Ready to report" which are getting close to deadline. I have tried manual updates with these results: 08/12/2008 18:05:11\|rosetta@home\|[sched_op_debug] Fetching master file 08/12/2008 18:05:11\|rosetta@home\|Fetching scheduler list 08/12/2008 18:05:16\|rosetta@home\|[sched_op_debug] Got master file; parsing 08/12/2008 18:05:16\|rosetta@home\|[sched_op_debug] Found 0 scheduler URLs in master file 08/12/2008 18:05:16\|rosetta@home\|[sched_op_debug] Deferring communication for 1 days 0 hr 0 min 0 sec 08/12/2008 18:05:16\|rosetta@home\|[sched_op_debug] Reason: 34 consecutive failures fetching scheduler list 08/12/2008 18:05:32\|rosetta@home\|[sched_op_debug] Fetching master file 08/12/2008 18:05:32\|rosetta@home\|Fetching scheduler list 08/12/2008 18:05:42\|rosetta@home\|[sched_op_debug] Got master file; parsing 08/12/2008 18:05:42\|rosetta@home\|[sched_op_debug] Found 0 scheduler URLs in master file 08/12/2008 18:05:42\|rosetta@home\|[sched_op_debug] Deferring communication for 1 days 0 hr 0 min 0 sec 08/12/2008 18:05:42\|rosetta@home\|[sched_op_debug] Reason: 35 consecutive failures fetching scheduler list 08/12/2008 18:05:57\|rosetta@home\|[sched_op_debug] Fetching master file 08/12/2008 18:05:57\|rosetta@home\|Fetching scheduler list 08/12/2008 18:06:02\|rosetta@home\|[sched_op_debug] Got master file; parsing 08/12/2008 18:06:02\|rosetta@home\|[sched_op_debug] Found 0 scheduler URLs in master file 08/12/2008 18:06:02\|rosetta@home\|[sched_op_debug] Deferring communication for 1 days 0 hr 0 min 0 sec 08/12/2008 18:06:02\|rosetta@home\|[sched_op_debug] Reason: 36 consecutive failures fetching scheduler list The significant error seems to be Found 0 scheduler URLs in master file Note my date format is European not USA. Keith.
25) Message boards : Number crunching : Minirosetta v1.32 bug thread (Message 55607) Posted 8 Sep 2008 by Keith T. Post: How far past the required runtime does a task need to go before it gets stopped by the watchdog? The messages in stderr indicate that this task has been removed from memory and resumed many times. If 5 such restarts occur with no progress being made (i.e. a checkpoint saved) the task will be ended. Otherwise, if the tasks uses more then 4 times the runtime preference, the watchdog will end it. Since it is waiting to run, it probably has to begin running again for the watchdog to get any time. The watchdog checks on it every 15 minutes. So, I would have expected it to have ended on the first restart where your runtime preference was lowered to 2 hours. Since it did not end, I guess I would abort that one. 11.5 hours and not to complete a single model, and not responding to the watchdog, sounds like something may be wrong there. I did not abort the task, I suspended all other tasks and then ran it again, deliberatly stopping it 5 times before a checkpoint. I also monitored the graphics and confirmed that the task was re-starting from model 0 at each restart. The task crashed after the 5th restart. http://boinc.bakerlab.org/rosetta/result.php?resultid=187758720 Here are the details as that url will probably be gone in a few days: Task ID 187758720 Name abinitio_homfrag_71_A_2ib0A_4443_10507_0 Workunit 171490091 Created 28 Aug 2008 4:31:58 UTC Sent 28 Aug 2008 4:42:45 UTC Received 2 Sep 2008 18:33:08 UTC Server state Over Outcome Client error Client state Compute error Exit status 0 (0x0) Computer ID 428259 Report deadline 7 Sep 2008 4:42:45 UTC CPU time 43431.4 stderr out <core_client_version>5.10.45</core_client_version> <![CDATA[ <stderr_txt> # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 Too many restarts with no progress. Keep application in memory while preempted. ====================================================== DONE :: 1 starting structures 43430.7 cpu seconds This process generated 0 decoys from 0 attempts ====================================================== BOINC :: Watchdog shutting down... BOINC :: BOINC support services shutting down... called boinc_finish </stderr_txt> <message> <file_xfer_error> <file_name>abinitio_homfrag_71_A_2ib0A_4443_10507_0_0</file_name> <error_code>-161</error_code> </file_xfer_error> </message> ]]> Validate state Invalid Claimed credit 117.814813845302 Granted credit 0 application version 1.32 I hope that I may get some credit retrospectively for my > 12 hours of CPU time. Keith. [edit] BTW the "wingman" who also used an AMD processor, got a "success". http://boinc.bakerlab.org/rosetta/workunit.php?wuid=171490091 CPU time 7905.563 stderr out <core_client_version>6.3.8</core_client_version> <![CDATA[ <stderr_txt> needs psipred_ss2 to run filters needs psipred_ss2 to run filters needs psipred_ss2 to run filters needs psipred_ss2 to run filters needs psipred_ss2 to run filters needs psipred_ss2 to run filters ====================================================== DONE :: 1 starting structures 7905.28 cpu seconds This process generated 2 decoys from 2 attempts ====================================================== BOINC :: Watchdog shutting down... BOINC :: BOINC support services shutting down... called boinc_finish </stderr_txt> ]]> Validate state Valid Claimed credit 25.8675057245436 Granted credit 20.8349439063512 application version 1.32 [/edit]
26) Message boards : Number crunching : Minirosetta v1.32 bug thread (Message 55477) Posted 2 Sep 2008 by Keith T. Post: http://boinc.bakerlab.org/rosetta/result.php?resultid=187758720 has been running on my AMD Athlon 2200+ since 28/08/08 08:45 (UTC+1). So far it has run for 11:33:44 and is currently "waiting to run". boinc_checkpoint_count.txt shows 97 boinc_init_count shows 1 87 The task appears to still be on the first decoy or model. I have changed my runtime prefs while this task has been running, to try to get it to finish and grant some credit. stderr.txt # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 28800 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 7200 # cpu_run_time_pref: 3600 # cpu_run_time_pref: 3600 I think it may have got stuck in a loop and is repeating the first model, as when I look at the graphics, the task does seem to be making progress. How far past the required runtime does a task need to go before it gets stopped by the watchdog?
27) Message boards : Number crunching : granted credit < 10% of claimed credit (Message 55275) Posted 25 Aug 2008 by Keith T. Post: I think the very low grant: Claimed credit 73.5154984583426 Granted credit 7.2629585763699 may have been due to exceptional factors. I had a Trojan program (now cleaned) running as well as BOINC , but I have noticed that other recent grants have also been low. I like to support Rosetta because of the useful work that it does, but I suspect that my hardware, AMD Athlon 2200+ with 768MB physical RAM is now on the low end of the scale compared to some of the "big boys". It also seems to have got worse since MiniRosetta, I noticed that there is already discussion of low credit grants in the Minirosetta v1.32 bug thread Keith.
28) Message boards : Number crunching : granted credit < 10% of claimed credit (Message 55264) Posted 24 Aug 2008 by Keith T. Post: I know BOINC credits don't buy anything, but it would be nice if Rosetta granted a similar ammount per hour to some of my other projects. A recent task http://boinc.bakerlab.org/rosetta/result.php?resultid=185984259 had a particularly low credit grant. You can see my other recent tasks at http://boinc.bakerlab.org/rosetta/results.php?userid=150379. I very rarely get more credit than claimed, but < 10% is probably an all time low! Keith
29) Message boards : Number crunching : Problems with version 5.96 (Message 53771) Posted 18 Jun 2008 by Keith T. Post: I am currently only running Rosetta on my old PII 233Mhz system. My faster system is busy running AstroPulse, SETI, Orbit and RALPH. I have a WU that started OK, but seems to have got stuck as the last checkpoint was @ 13:04, over 2 hours ago. The task id is t405__CASP8_JUMPAB_TYPE2_RES81to192_SAVE_ALL_OUT_BARCODE__3785_15981_0. I know that this system is very slow by modern standards, but it has managed at least 9 other Rosetta tasks OK recently http://boinc.bakerlab.org/rosetta/results.php?hostid=455894, and quite a few for RALPH as well http://ralph.bakerlab.org/results.php?hostid=14021. Keith
30) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52596) Posted 18 Apr 2008 by Keith T. Post: Thanks for the reply. I had 2 recent CAPRI15 WU's: FRA_t038_CAPRI15_1n82_1_IGNORE_THE_RESTt038_1_input.pdb_3060_216104_0 FRA_t038_CAPRI15_1n82_1_IGNORE_THE_RESTt038_1_input.pdb_3060_235298_0 First one: CPU time 314.0625 stderr out <core_client_version>5.10.45</core_client_version> <![CDATA[ <message> Incorrect function. (0x1) - exit code 1 (0x1) </message> <stderr_txt> # cpu_run_time_pref: 3600 # random seed: 2888897 Unhandled Exception Detected... - Unhandled Exception Record - Reason: Access Violation (0xc0000005) at address 0x7C910F29 read attempt to address 0x00000000 Engaging BOINC Windows Runtime Debugger... # cpu_run_time_pref: 3600 ERROR:: Exit from: .initialize.cc line: 1614 </stderr_txt> ]]> Validate state Invalid Claimed credit 0.840314964353539 Granted credit 0 Second one: CPU time 17240.72 stderr out <core_client_version>5.10.45</core_client_version> <![CDATA[ <stderr_txt> # cpu_run_time_pref: 3600 # random seed: 2869703 ******************************************************************** Rosetta score is stuck or going too long. Watchdog is ending the run! CPU time: 17240.7 seconds. Greater than 4X preferred time: 3600 seconds ******************************************************************** GZIP SILENT FILE: .aat038.out </stderr_txt> ]]> Validate state Valid Claimed credit 46.1297831235163 Granted credit 80 The first one really ran for > 4hours but the reported time is 314 seconds.
31) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52592) Posted 18 Apr 2008 by Keith T. Post: FRA_t038_CAPRI15_1n82_1_IGNORE_THE_RESTt038_1_input.pdb_3060_235298_0 finally finished with Sucess. stderr out <core_client_version>5.10.45</core_client_version> <![CDATA[ <stderr_txt> # cpu_run_time_pref: 3600 # random seed: 2869703 ******************************************************************** Rosetta score is stuck or going too long. Watchdog is ending the run! CPU time: 17240.7 seconds. Greater than 4X preferred time: 3600 seconds ******************************************************************** GZIP SILENT FILE: .aat038.out </stderr_txt> ]]> Validate state Valid Claimed credit 46.1297831235163 Granted credit 80
32) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52591) Posted 18 Apr 2008 by Keith T. Post: I've tried to explain that, from what you describe, the activity you are seeing sounds normal. And I always explain that some types on tasks do not checkpoint as frequently as others. In fact, some only checkpoint when a model is completed... which can be anywhere from 5 minutes to 5 hours. Just depends what type of task it is. Given your change in title, I wanted to clarify your "problems with...". Is the only problem you are observing that they take a long time to checkpoint, and to complete their first model (which in your case will take longer then your runtime preference, and cause them to report in)? Or are there other things you are seeing unique to the CAPRIs? OK, I know I have my run time prefs set on the low side, but it is a valid setting. My PC has 768MB RAM, Windows XP, AMD Athlon XP 2200+ CPU. I usually run BOINC 24/7 with 75% memory usage while "in use" 100% while idle. Most other Rosetta WU's have created at least 1 decoy/model within 1.5 hours. I just checked back in my BoincView logs and I have had some sucess with previous CAPRI15 WU's. It just seems to be these last 2 that have gone on for much longer than normal without producing 1 decoy/model. I also took a brief look at the graphics window, and the molecule looks much more complex than usual. I will let the current model run as long as the CPU does not drop to 0% again, it is the last CAPRI15 that I currently have.
33) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52587) Posted 18 Apr 2008 by Keith T. Post: Going to change the title of this to make it more meaningful from "How far past target runtime will it go?" to "Problems with CAPRI15 WU's" I have another CAPRI15 WU FRA_t038_CAPRI15_1n82_1_IGNORE_THE_RESTt038_1_input.pdb_3060_235298 which has also gone well past 3 hours without checkpointing. It is currently preempted by other tasks that have gone into "high-priority", but it is still in memory.
34) Message boards : Number crunching : Problem on Ubuntu 7.10 (Message 52586) Posted 18 Apr 2008 by Keith T. Post: Some Rosetta tasks need more than 256MB to run. I think some of the current tasks may need 400MB or more. Also check what % of your memory is available to BOINC, it could be as low as 50% when the system is "in use".
35) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52570) Posted 17 Apr 2008 by Keith T. Post: The task ran for another 5 minutes when it re-started then errored out. The reported time is 314 seconds, but it really ran 3hr 55min longer than that. I have kept a copy of the slot folder when it stalled earlier. If the developers would like a Zip of this, I can send it. I don't supose there is any chance of getting a credit adjustment for this task.
36) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52568) Posted 17 Apr 2008 by Keith T. Post: Thanks for the reply, I was aware that 1 hour can be too short for some models/decoys. I reduced it to 1 hour a few weeks ago when RALPH started getting a lot more work than usual and I also added a few other projects. Rosetta currently has 8% resource share as I run a lot of projects on 1 PC. Some of these like LHC, SIMAP, and RALPH often have no work, so the true resource share is usually closer to 10 or 15% BOINC always manages to return tasks in time, but I dropped the target time for Rosetta when things were getting tight a few weeks ago. I read about the Watchdog time elsewhere while I was waiting for a reply. Rosetta is still at -9200 STD so I will probably give it an artificial boost in the next few hours as I want to see what this task will do today.
37) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52556) Posted 17 Apr 2008 by Keith T. Post: When I shut down BOINC after 15 minutes of no activity the following files were written or updated: stdout.txt stderr.txt farlxcheck I then restarted BOINC and a SETI task restarted. Rosetta is now on STD of -11428 seconds, so I will have to wait a few hours for this task to restart unless I suspend all my other projects. I have also made a copy of the slot folder in case this task errors out when it re-starts. Keith
38) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52555) Posted 17 Apr 2008 by Keith T. Post: Update on this task. CPU usage just dropped to 0%. Looked in the slot folder and rosetta_random and rosetta_decoy_cnt have updated about 4 minutes ago. "Show Graphics" button now does nothing but the button is not "greyed out". BOINC Manager progress has stopped at 3:55:20, Progress stopped at 95.924% Going to shut down BOINC as no other tasks are running.
39) Message boards : Number crunching : Problems with some CAPRI15 WU's (Message 52554) Posted 17 Apr 2008 by Keith T. Post: Task FRA_t038_CAPRI15_1n82_1_IGNORE_THE_RESTt038_1_input.pdb_3060_216104 I have my target runtime set to 1 hour (Athlon XP 2200+). I know that Rosetta will alway complete at least 1 "decoy". My current task started over 3.5 hours ago by wall clock time. 3hr 27min according to BOINC Manager. Steps are still incrementing on the "Show Graphics" screen currently at 56804. Looked in the BOINC "slot" folder and the last checkpoint file was written over 2.5 hours ago, 56 minutes after the task started. What would happen if I closed down BOINC, or a power failure happened?
40) Message boards : Number crunching : No work sent? (Message 49262) Posted 1 Dec 2007 by Keith T. Post: ... a few days ago I noticed that Pete Leman was successfully crunching with win98 so I decided to install boinc on an old win98 machine just as Rosetta went down for the couple of days! I've just been bashing my head to get it running, I had to keep clearing disk till I had well over 1.5GB despite 200MB supposedly being the minimum. Finally I got the same memory shortage error as everyone else - I thought it was just me: what do we do next? it's not some virtual memory thing is it? if one app. is heavy duty, I don't think you can switch on and off each application (5.82 & 5.85 etc.) separately on Rosetta can you? b.t.w. the PC is a 600MHz athlon with 384MB. on the main pc I do long wu's like cpdn and einstein but projects with short wu's are best for the old banger. my hope was to use Rosetta on any other host I set up to keep the CPIDs in line and all tied together. cheers / another Pete :-) Good Luck getting Rosetta to run on you old Win98 Athlon. I thought BOINC checked RAM, not Virtual Memory, but I could be wrong about that. I ran a few Rosetta WU's on a Win98 Pentium II 233MHz with 512MB RAM last winter. the host id is here http://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=455894. That machine is definitly a space heater when crunching @ 100% processor use. It is currently offline, but I may get it back online running Linux in the next few weeks. I have an even older Win98 box with only 128MB RAM that runs SETI, SETI Beta, LHC and Leiden, but I dont think I will try attaching that one to Rosetta! I noticed that your computers are hidden, what is the host id of your Win 98 box?

Previous 20 · Next 20