Posts by ramostol

21) Message boards : Number crunching : Minirosetta v1.40 bug thread (Message 57460) Posted 2 Dec 2008 by ramostol Post: My (MacBook) "abinitio_nohomfrag_70_A_1unpA_4466"-tasks show a failure rate of three out of four, all failures terminate after some hours' computing with finishing file absent. Cannot link to a result, as I am unable to report to the project at the moment.
22) Message boards : Number crunching : Minirosetta v1.40 bug thread (Message 57044) Posted 18 Nov 2008 by ramostol Post: The tasks cs_jumping_abrelax_6PNAS_proteins3_homo_bench_cs_jumping_abrelax_cs_flua_olange_4728_19390_0 and 1bm8__BOINC_ABRELAX_SPLIT_SPLIT2_IGNORE_THE_REST-S25-9-S3-3--1bm8_-_4768_9_0 do not stop the work. It is running 14 hours, usually takes 4 hours. Interrupting the work... I observed on my MacBook this morning (it's working by itself in peace and quietude) that the cs_jumping wus appear to complete normally, but seem (according to the message window) to restart once or twice in the computing process without an obvious explanation.
23) Message boards : Number crunching : Minirosetta v1.40 bug thread (Message 56806) Posted 10 Nov 2008 by ramostol Post: My MacBook refuse to compute any loopbuild_boinc4_hombench_-task, cf this result <core_client_version>6.2.18</core_client_version> <![CDATA[ <stderr_txt> # 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 671.186 cpu seconds This process generated 1 decoys from 1 attempts ====================================================== BOINC :: Watchdog shutting down... BOINC :: BOINC support services shutting down... called boinc_finish </stderr_txt> ]]> Other tasks complete as exptected.
24) Message boards : Number crunching : Report "hombench_..." issues here! (Message 56432) Posted 20 Oct 2008 by ramostol Post: You just can't win'em all: http://boinc.bakerlab.org/rosetta/workunit.php?wuid=182132039 hombench_mtyka_foldcst_simple_foldcst_simple_t303___4611_4660 Task ID: 199398597 CPU time: 58,300.45 [!!] Claimed credit: 389.05 Granted credit: 12.00 [!!] Computer: GenuineIntel Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz [x86 Family 6 Model 23 Stepping 6] Number of CPUs 2 Operating System Darwin 9.5.0 Memory 4096 MB Cache 976.56 KB Swap space 92321.28 MB
25) Message boards : Number crunching : Rosetta 5.98 problem. (Message 56269) Posted 7 Oct 2008 by ramostol Post: short version is that 5.98 is an older program and is not compatible with boinc 6.2.15 for graphics. the 1.32 tasks will be ok. I have a Mac with a 667Mhz processor and 512MB of ram. Rosetta runs fine, but whenever I click on the "Show Graphics" button, the completion bar jumps to 100% and it says that there was a computational error. What can I do to fix this? I'm running BOINC v6.2.15 and Rosetta Beta 5.98 Further experiments indicate that this is a permissions problem, cf this failed wu. You seem to get it when running Boinc as a user with no administrative permissions.
26) Message boards : Number crunching : Expired deadline (Message 56140) Posted 1 Oct 2008 by ramostol Post: This issue of reissuing a task to someone that may not receive credit for it has been on the BOINC "to do" list for over a year. Here is a link to the trac item: Server reissues task more then "total" specified The changeset [trac]changeset:276[/trac] describes a different case, where third task is being errorneously reissued, although the total=2. Would the problem mentioned in this thread be solved using 2-2-2 limit settings? minimum quorum 1 initial replication 1 max # of error/total/success tasks 2, 2, 2 (Surely it could take longer to discard the WU from server.) Peter My very personal theory is that the text "max # of error/total/success tasks" is misleading and should read "max # of error/total/success results". This situation may be created because Boinc somehow does not consider tasks exceeding the deadline (Server state: Over ; Outcome: No reply ; Client state: New") as results. Then if a result is returned to the server after the deadline in a situation where three computers have received this task for computing, this increases the number of total results in disfavour of the third participant. By the way, I doubt that we may conclude from "max # of error/total/success tasks" = 1, 2, 1 that Rosetta should not send out more than 2 replications of the same task. By the same interpretation we should have to conclude that Rosetta terminates a task upon receiving one result with "Client error/Compute error". It doesn't, it terminates upon receiving more than 1, that is 2, error results. And Rosetta is perfectly capable of accepting more than 1 (again = 2) success results under ordinary circumstances, giving proper credits to everyone.
27) Message boards : Number crunching : Expired deadline (Message 56139) Posted 1 Oct 2008 by ramostol Post: Actually, once the WU hsa been reassigned, there is a race: the first of the two computers to report will get credit, and the second will get a Validation Error and no credit. This discussion seems to be going a bit too fast. I should like to see some documentation that Boinc/Rosetta gives credits merely to one computer in cases where two computers have returned results for the same task. I have used a slow but reliable computer for one and a half year. I see this situation quite often, receiving tasks expired or crashed on other computers (and occasionally fighting time limits myself), and I have tried to follow what happens to these tasks. I have never - repeat: never - observed that Rosetta has refused credits to one of two computers delivering valid results for the same task. Rosetta will use the first incoming result as a canonical result, but credits are delivered to everyone. And I think this is a proper behaviour. Boinc is designed to run unattended, and participants should not need to worry unnecessarily about deadlines or task duplications. There is of course one limitation. When Rosetta has received one valid result the project is satisfied. The task will stay as statistics for the successful cruncher for a limited period and then disappear from the server. And at that point no one will be able to return results and get credits. As for aborting tasks passing deadlines I am in two minds. If you see that another computer has delivered a valid result then by all means abort your replication. But an abortion of a task weakens its overall chances of success. I have observed quite a few perfectly sound tasks being cancelled on the server because the first cruncher aborted for time reasons (thereby registering a compute error by the server) and the next receiver crashing or giving in (because some models are too lengthy, what do I know?). Anyhow, I now wonder if it is better for the project to register two successes for the same task than none at all.
28) Message boards : Number crunching : Credits going mad !!! (Message 56077) Posted 29 Sep 2008 by ramostol Post: Please have a look at my workunits : http://boinc.bakerlab.org/rosetta/workunit.php?wuid=176388677 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=176388673 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=176317120 All finished with "Rosetta score is stuck or going too long. Watchdog is ending the run!" and scored incredibly high !!!! Don't worry, this is standard Rosetta beta behaviour. Your configured runtime is 1 hour (3600 sec.). If your computer receives work units where the first model needs more than 4 hours (4 x configured runtime) to complete, Rosetta will finish computing after about 4 hours 15-30 minutes and award you 80 credits for your crunching efforts. You receive 80 credits regardless of your actual computing time. It is an effective way to boost one's credits, but the results are scientifically worthless - and such work units are not sent on to other crunchers and are dead to the world. For these reasons it might be advisable to increase the configured runtime a bit, even if you lose credits this way.
29) Message boards : Number crunching : Report long-running models here (Message 55800) Posted 16 Sep 2008 by ramostol Post: I'd like to start a thread for reports of long running models. Pure mindreading. And you may be needing this discussion as a sticky... The theory is that specific models within a task are taking significantly longer then others, ... This part is a bit more than a theory. My documentation disappeared last week, but I remember a wu starting with a model lasting less that 6 hours and concluding with model 2 lasting around 17 hours, and a wu starting with models running about an hour finishing with a model 9 running 4 hours longer than the default runtime. My present results page consists of three tasks: Task ID: 190622469 WU ID: 174119129 8 Sep 2008 15:44:37 UTC 15 Sep 2008 16:14:01 UTC Over Success Done CPU: 45,044.32 Claimed: 83.08 Granted: 22.40 (2 models) (25% of claim is a normal result for my computer these days) Or81__BOINC_SYMM_FOLD_AND_DOCK_RELAX-Or81_-nmr_foldanddock__4445_17477_1: Task ID: 190080493 WU ID: 171441384 6 Sep 2008 11:55:27 UTC 15 Sep 2008 8:21:41 UTC Over Success Done CPU: 124,679.00 (34h) Claimed: 229.96 Granted: 33.70 (1 model) (11% of claim, less than 1 credit per CPU hour) amer__BOINC_SYMM_FOLD_AND_DOCK_RELAX-amer_-STIH_tetr_4437_41444_1: Task ID: 190080492 WU ID: 171441412 6 Sep 2008 11:55:27 UTC 12 Sep 2008 9:40:47 UTC Over Success Done CPU: 204,936.90 (56h 55min) Claimed: 368.54 Granted: 64.58 (1 model) # The first task included solely for comparison of benchmarks. # The middle task is one of my poorest results as for credits. # The third task with a record-breaking model demanding 57 hours of computing was also on the low side. (It must be noted that I was the second cruncher of all these wus.) But one has to be grateful that such models now are checkpointing. The inability to predict the runtime needed for such large wus is a bit of a problem, as they upset the computer's time schedule and downloading ability. I wonder if we could at least be helped by changing the graphics window to display "Model 1 Step xxxx of totally nnnnn steps" Then one would at least see if the end is near... Specifications: iBook G4 1.2 GHz PPC, 768 MB RAM MacOS 10.3.9 BOINC 6.2.18 Rosetta 5.98
30) Message boards : Number crunching : Rosetta 5.98 problem. (Message 55613) Posted 8 Sep 2008 by ramostol Post: short version is that 5.98 is an older program and is not compatible with boinc 6.2.15 for graphics. the 1.32 tasks will be ok. I have a Mac with a 667Mhz processor and 512MB of ram. Rosetta runs fine, but whenever I click on the "Show Graphics" button, the completion bar jumps to 100% and it says that there was a computational error. What can I do to fix this? I'm running BOINC v6.2.15 and Rosetta Beta 5.98 Running PowerMac and all the Boinc 6.2.x updates I have never had problems with the Rosetta (WCG is another matter) "show graphics screen" (I have some more Mhz and a bit more ram though...). But if I remember correctly, someone described a similar problem (graphics?/screensaver?) a while ago and had managed to solve it by reducing the CPU used for crunching (to max 80 % of the total CPU I think).
31) Message boards : Number crunching : MAC PowerPC - There was work for other platforms (Message 55601) Posted 8 Sep 2008 by ramostol Post: ramostol's link above should be http://boinc.bakerlab.org/rosetta/forum_thread.php?id=3934&nowrap=true#51195 ;) Thanks. Computer trouble forces me to use browsers obviously not behaving in a manner that I am used to...
32) Message boards : Number crunching : claimed credit: 50.12, granted credit: 9.96 (Message 55577) Posted 6 Sep 2008 by ramostol Post: No, this is not a bug, nor a specific miniRosetta issue. Invoking all possible caveats I shall try to give a possible explanation: You will notice that the wu (1 model) in question ran quite long compared to your default runtime and compared to other models in wus of the same category. This may be a clue. Credits are based on averages. And while it is easy to assume that all models that might be generated within a certain wu need approximately the same time to complete, this is not always the case. Effective CPU runtime may differ with several hundred percent between models within the same wu. If a special type of wu consists of lots of short models and a few longer ones this will of course affect the average credits per model. The losers are those completing the small number of large models. In all fairness, one may also get a surprise the other way when a series of long models suddenly will be interrupted by a quick decoy earning lots of "undeserved" credits.
33) Message boards : Number crunching : MAC PowerPC - There was work for other platforms (Message 55576) Posted 6 Sep 2008 by ramostol Post: These messages (#51329, 51357, and 51362) might be of some interest to you.
34) Message boards : Number crunching : Which file holds the run time parameter ? (Message 54923) Posted 5 Aug 2008 by ramostol Post: ...Yeah, I thought it was some type of xml file, went wandering around a bit, but didn't find any with the value of 10800. @N B I T: Yeah, saw that, but this is whats in my file, no 10800: <cpu_run_time>0</cpu_run_time> Since 10800 (3h) is the default Rosetta runtime period and is never defined by the actual number itself, "0" is probably to be expected in this situation?
35) Message boards : Number crunching : Problems with Rosetta version 5.98 (Message 54142) Posted 2 Jul 2008 by ramostol Post: This WU stii runing at 17:22:00 CPU ... I dont think it is worth keeping this WU going As long as the CPU is running, the WU is alive and well. My largest WU needed 46 hours to complete (and 12 hours default runtime of course) - the time needed depends on your computer. So if you're not too impatient...
36) Message boards : Rosetta@home Science : Rosetta vs POEM (Message 53597) Posted 9 Jun 2008 by ramostol Post: In response to a question on this thread, I tried to find out about the science behind POEM. I didn't find anything on the web beyond the POEM home page, which has no details. anybody know more? If still needed, this page (no link found on the POEM@home page?) seems to present a little more background.
37) Message boards : Number crunching : Vanished word units? (Message 53160) Posted 19 May 2008 by ramostol Post: For the record: My Tasks for User Account insists that my computer has received the following wus: http://boinc.bakerlab.org/rosetta/workunit.php?wuid=149489497 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=149488655 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=149486989 http://boinc.bakerlab.org/rosetta/workunit.php?wuid=149488150 The log file of my computer says no wus at all have been received in the period indicated (morning May 15th at 9:11 and 9:17 UTC). No such wus have been completed or are waiting on line, so they seem to have vanished somewhere.
38) Message boards : Number crunching : Problems with version 5.96 (Message 52846) Posted 3 May 2008 by ramostol Post: This f1_atpase_beta_relax_31904_9833_1 is still alive and kicking after 45 1/2 hour of computing. The graphics are folding, the steps are increasing (presently at about model 1 step 2435), but it is enjoying the experience too much to complete. I confess my curiosity is roused, but now I have to evaluate the situation... For those interested in statistics: The first model of this task needed 45 h 52 min to complete. With no checkpointing. I admit my laptop is small and elderly, but I believe that this is no task for unprepared crunchers.
39) Message boards : Number crunching : Problems with version 5.96 (Message 52831) Posted 2 May 2008 by ramostol Post: My f1_atpase_beta_relax_3104_42290_0 on Linux was forcibly stopped by watchdog: ........ # cpu_run_time_pref: 14400 ..... ******************************************************************** Rosetta score is stuck or going too long. Watchdog is ending the run! CPU time: 60899.9 seconds. Greater than 4X preferred time: 14400 seconds ******************************************************************** Similar situation on Macintosh: This f1_atpase_beta_relax_31904_9833_1 is still alive and kicking after 45 1/2 hour of computing. The graphics are folding, the steps are increasing (presently at about model 1 step 2435), but it is enjoying the experience too much to complete. I confess my curiosity is roused, but now I have to evaluate the situation... By the way: I observe that 2 of the 4 remaining f1_atpase-wus queued up on my computer have previously crashed (quite early in the computing process) on other computers.
40) Message boards : Number crunching : Huge splurge of client errors since reseting (Message 52676) Posted 24 Apr 2008 by ramostol Post: Right, so after A LOT of rummaging I found a message from the Boinc mailing list describing the apparent need to recompile the latest client for Tiger - with no mention of Panther, which my semi-retired Mac mini is running. Back-grading to a (really very) old version of the client seems to have got the project working again. Who do I tell that the system requirements pages for Boinc/Mac need to be corrected? Do they need to be corrected? I am currently running BOINC 6.10.16 on Panther 10.3.9 and have observed no problems whatsoever with the 5.x and 6.x BOINC beta releases (other than problems also found in the stable versions of course).

Previous 20 · Next 20