Posts by tralala

41) Message boards : RALPH@home bug list : Bug reports for Ralph 5.05 and higher (Message 1377) Posted 26 Apr 2006 by tralala Post: Both WU I tried finished valid but both results show a warning: WARNING! error deleting file .aah002.out However no such file is present on my computer any longer. http://ralph.bakerlab.org/results.php?userid=1266
42) Message boards : Feedback : Limit Ralph WUs per day (Message 1374) Posted 26 Apr 2006 by tralala Post: I agree on the topic that as many scenarios as possible should be tested on Ralph. However I still think fast turnaround times to be critical. With two week deadlines you now get reported back 4.99-WUs. They are clearly of less value at the moment than fresh 5.05-WUs. Short deadlines will not only force the client into EDF-Mode (and thus priorizing Ralph-Units) but also prevent BOINC from downloading more WUs. So with shorter deadlines you achieve the same effect as with limiting the quota: You prevent hosts building up large caches. But at the same time you avoid penalizing hosts which return a lot of errors quickly and you reduce average turnaround time. The only disadvantage is that due to EDF-Mode less switching will be done. But not all hosts will go into EDF, just those who still request large caches. The runtime can always be set up server side (as they already do now). So to summarize: Low quota: + no large caches - penalizing error-reporters Short deadlines: + no large caches + faster turnaround times - less switch-testing I see a 1 point-advantage of shorter deadlines. ;-) Best would probably a mix of short and long deadlines to guarantee the maximum variety of testing.
43) Message boards : Feedback : Limit Ralph WUs per day (Message 1371) Posted 26 Apr 2006 by tralala Post: I read the linked thread and if I understand it the decision was already taken to limit maximum WU per host to something like 12 (I have 20 at the moment). Rhiju uses the term quota for that, right? I think there is even a better way to ensure minimum turnaround and most diverse testing: shorten the deadlines! I think a deadline of 2 days is ok given the frequent updates of the app. Actually the devs need the results within a day. A shorter deadline will also prevent hosts from builduing up big caches and there is no need to limit the quota to such harsh figures feet1st proposes. Also I would restrict the user option for run-time to 12 hours to ensure fast turnaround times (or deactivate it and send out WUs with a diverse set of runtimes as needed and as done for the latest 5.04 WUs). With short deadlines there is no need to limit the number of WUs server-side, since clients can't build large caches and you can cancel the obsolete WUs quickly after you release a new app. Any disadvantages for shortening the deadlines?
44) Message boards : RALPH@home bug list : Bug reports for Ralph 5.05 and higher (Message 1369) Posted 26 Apr 2006 by tralala Post: Now it's: 26/04/2006 10:48:22\|ralph@home\|Message from server: Server has software problem 26/04/2006 10:48:22\|ralph@home\|Project is down
45) Message boards : RALPH@home bug list : Bug reports for Ralph 5.05 and higher (Message 1368) Posted 26 Apr 2006 by tralala Post: If I try to fetch work I get a "Project is down" message.
46) Message boards : RALPH@home bug list : Bug reports for Ralph 5.04 (Message 1344) Posted 25 Apr 2006 by tralala Post: Thanks for continuing posts of ralph errors. This will probably be our last development release on ralph before putting the app on Rosetta@home. We really need to know if anything is fundamentally wrong with this one! Then put up a few more WUs! Why so few testing?
47) Message boards : RALPH@home bug list : Bug reports for Ralph 5.03 (Message 1319) Posted 23 Apr 2006 by tralala Post: This WU was aborted by the watchdog on another machine but fished ok on my machine: http://ralph.bakerlab.org/workunit.php?wuid=82603 Do you still receive the finished models if the watchdog kills a WU which gest stuck on model x?
48) Message boards : Feedback : Why so little testing on Ralph? (Message 1306) Posted 22 Apr 2006 by tralala Post: There really is no science use made of the RAPLH protein results beyond testing the application itself. If a RAALPH application generates errors then it will not be deployed in Rosetta. Also RALPH is used to test Work Unit stability, and to test bug fixes. So the actual protein results generated by RALPH processing have almost no use as science results beyond the fact that they run to success or they don't. I wonder why. Aren't the proteins and the application the same which are eventually deployed to Rosetta? The results should be of the same quality as the results from Rosetta. Are there technical reasons why the results can't be used?
49) Message boards : RALPH@home bug list : Bug reports for Ralph 5.02 (Message 1296) Posted 22 Apr 2006 by tralala Post: Out of seven six have crashed: http://ralph.bakerlab.org/results.php?userid=1266 Although I have 5.4.3 installed I didn't get a large crash-dump
50) Message boards : Feedback : Why so little testing on Ralph? (Message 1292) Posted 22 Apr 2006 by tralala Post: Hi, I just read on Rosetta that 5.01 has problems with some WUs. I wonder why you didn't create more jobs for 5.01 here on Ralph? I wanted to check out 5.01 on Ralph before you released it to Rosetta but there was already no work available. For Ralph there is more computing power present than you seem to use. Soem errors show only up in big samples so I suggest to increase testing here on Ralph. Or is the science returned on Ralph not comparable to that returned on Rosetta?
51) Message boards : RALPH@home bug list : Report \"stuck at 1%\" bugs here (Message 1224) Posted 18 Apr 2006 by tralala Post: Tony, I agree with you as well. The directive from the dev's is not to abort work units unless specifically asked to. http://ralph.bakerlab.org/forum_thread.php?id=18 If it's not giving you any problems and progressing properly, let it crunch! David, that's part of the question I need answered, it's a timex, in that it keeps crunching, graphics work well, all the bits move, % done advances, CPU time advances, and even the "estimate to completion" moves, but it keeps getting higher. This could be due to the way win98 counts time. I see it run "Ab initio", then switch to "full atom relax", then it loops back to "ab initio" and starts all over again. All the while staying on "model 1". Is this how others see it working? I was thinking it did "ab initio", then "full atom relax", and then switched to the next model, but I'm not sure which way is "normal". tony @mmciastro I think you made your point now you should abort the WU. The error loop was discovered correctly from you and will help the devs no need to observe that loop another 100 hours. And yes there is already version 5.00 so abort all the 4.99 WUs since now the results of 5.00 do matter.
52) Message boards : RALPH@home bug list : OLD- Bug reports for Windows Ver - 5.00 (and higher) (Message 1092) Posted 12 Apr 2006 by tralala Post: http://ralph.bakerlab.org/result.php?resultid=85437

Previous 20