Posts by zombie67 [MM]

41) Message boards : RALPH@home bug list : Bug Reports for 5.45 (Message 2763) Posted 5 Feb 2007 by zombie67 [MM] Post: Please turn on RAC decay. http://boinc.berkeley.edu/project_tasks.php
42) Message boards : RALPH@home bug list : RAC decay (Message 2753) Posted 1 Feb 2007 by zombie67 [MM] Post: Can someone please turn on RAC decay for RALPH? BUMP BUMP! BUMP! [TAP TAP TAP] ...Is this thing on? Instructions are here: http://boinc.berkeley.edu/project_tasks.php
43) Message boards : RALPH@home bug list : RAC decay (Message 2744) Posted 30 Jan 2007 by zombie67 [MM] Post: Can someone please turn on RAC decay for RALPH? BUMP BUMP! BUMP!
44) Message boards : RALPH@home bug list : RAC decay (Message 2722) Posted 28 Jan 2007 by zombie67 [MM] Post: Can someone please turn on RAC decay for RALPH? BUMP
45) Message boards : RALPH@home bug list : RAC decay (Message 2709) Posted 25 Jan 2007 by zombie67 [MM] Post: Can someone please turn on RAC decay for RALPH?
46) Message boards : Number crunching : RAC script (Message 2708) Posted 25 Jan 2007 by zombie67 [MM] Post: Can this be done on Ralph to? http://boinc.bakerlab.org/rosetta/forum_thread.php?id=2219#25556 Anders n BUMP! BUMP! BUMP!
47) Message boards : Number crunching : RAC script (Message 2663) Posted 8 Jan 2007 by zombie67 [MM] Post: Can this be done on Ralph to? http://boinc.bakerlab.org/rosetta/forum_thread.php?id=2219#25556 Anders n BUMP!
48) Message boards : Number crunching : why so little test time? (Message 2626) Posted 15 Dec 2006 by zombie67 [MM] Post: I noticed that the new applications have had a very short test time before migrating to Rosetta from RALPH. I have also noticed that there have been a lot of revisions in a short time. Would it help to increase RALPH time before releasing to Rosetta?
49) Message boards : RALPH@home bug list : Bug Report for Ralph 5.41 (Message 2582) Posted 6 Dec 2006 by zombie67 [MM] Post: http://ralph.bakerlab.org/result.php?resultid=340416 <core_client_version>5.4.9</core_client_version> <message> process exited with code 131 (0x83) </message> <stderr_txt> Direct call to xwin_graphics_event_loop() Graphics-thread now waiting for client-message... # random seed: 2817412 # cpu_run_time_pref: 3600 SIGSEGV: segmentation violation Crashed executable name: rosetta_beta_5.41_powerpc-apple-darwin built using BOINC library version 5.7.5 Machine type PowerPC 970 System version: Macintosh OS 10.4.8 build 8L127 Wed Dec 6 01:10:05 2006 Stack frame backtrace: # Flags Frame Addr Caller PC Return Address Symbol === === ========== ========== ===================== 1 FP- 0x00000000 0x00000000 Thread number 0: Stack frame backtrace: # Flags Frame Addr Caller PC Return Address Symbol === === ========== ========== ===================== 1 F-- 0x00000000 0x90040978 mach_wait_until + 0x8 2 --- 0xbffff360 0x90040744 nanosleep + 0x184 3 --- 0xbffff400 0x90040570 sleep + 0x90 4 --- 0xbffff470 0x00d66e70 5 --- 0xbffff4c0 0x00d673e8 6 --- 0xbffff5f0 0x00d631fc 7 --- 0xbffff640 0x00d630a4 8 --- 0xbffff6b0 0x006eeadc 9 --- 0xbffff700 0x00002474 10 --- 0xbffff760 0x0000231c 11 -P- 0xbffff7a0 0x00000000 12 FP- 0x00000000 0xffffffffffffffff Thread number 2: Stack frame backtrace: # Flags Frame Addr Caller PC Return Address Symbol === === ========== ========== ===================== 1 F-- 0x00000000 0x90040978 mach_wait_until + 0x8 2 --- 0xf01011a0 0x90040744 nanosleep + 0x184 3 --- 0xf0101240 0x90040570 sleep + 0x90 4 --- 0xf01012b0 0x00d4e2d4 5 --- 0xf0101320 0x00d5558c 6 --- 0xf0101e30 0x9002b508 _pthread_body + 0x60 7 -P- 0xf0101f00 0x00000000 8 FP- 0x00000000 0xffffffffffffffff Thread number 3: Stack frame backtrace: # Flags Frame Addr Caller PC Return Address Symbol === === ========== ========== ===================== 1 F-- 0x00000000 0x90040978 mach_wait_until + 0x8 2 --- 0xf0182b90 0x90040744 nanosleep + 0x184 3 --- 0xf0182c30 0x90040570 sleep + 0x90 4 --- 0xf0182ca0 0x00cb76e0 5 --- 0xf0182e30 0x9002b508 _pthread_body + 0x60 6 -P- 0xf0182f00 0x00000000 7 FP- 0x00000000 0xffffffffffffffff Exiting... exit() was called from worker-thread </stderr_txt>
50) Message boards : Number crunching : Preferred Run Time? (Message 2501) Posted 7 Nov 2006 by zombie67 [MM] Post: Thanks for your thoughts. Your approach seems reasonable to me.
51) Message boards : Number crunching : Preferred Run Time? (Message 2491) Posted 7 Nov 2006 by zombie67 [MM] Post: With Rosetta, I understand that there is no "better" run time from a science perspective. But what is the best for RALPH? Is the goal to just to see if a WU works? In which case, would a minimum run time be best, to process the largest variety of WUs? Or is it better to try to run as many models from the same WU?
52) Message boards : RALPH@home bug list : Bug reports for Ralph 5.37 through 5.40 (Message 2488) Posted 7 Nov 2006 by zombie67 [MM] Post: Here are 4 (1x 5.38 & 3x 5.37) http://ralph.bakerlab.org/result.php?resultid=315272 5.38 </stderr_txt> <message> <file_xfer_error> <file_name>DOC_1STF_p2_fa_relax_from_native_1462_4_1_0</file_name> <error_code>-161</error_code> </file_xfer_error> </message> http://ralph.bakerlab.org/result.php?resultid=313951 5.37 <core_client_version>5.4.11</core_client_version> <message> The system cannot find the path specified. (0x3) - exit code 3 (0x3) </message> <stderr_txt> # random seed: 2872068 # cpu_run_time_pref: 21600 </stderr_txt> http://ralph.bakerlab.org/result.php?resultid=313010 5.37 <core_client_version>5.4.11</core_client_version> <stderr_txt> input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 Too many restarts with no progress. Keep application in memory while preempted. ====================================================== DONE :: 0 starting structures built 29 (nstruct) times This process generated 0 decoys from 0 attempts ====================================================== BOINC :: Watchdog shutting down... BOINC :: BOINC support services shutting down... </stderr_txt> <message> <file_xfer_error> <file_name>1ogw__ETABLE_TEST_ABRELAX_rhh13sm6__1452_10_0_0</file_name> <error_code>-161</error_code> </file_xfer_error> </message> http://ralph.bakerlab.org/result.php?resultid=313009 5.37 core_client_version>5.4.11</core_client_version> <stderr_txt> input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 input_etable: reading etable... dsolv input_etable: WARNING etable types don't match! expected dsolv,606 got dsolv,721 Too many restarts with no progress. Keep application in memory while preempted. ====================================================== DONE :: 0 starting structures built 29 (nstruct) times This process generated 0 decoys from 0 attempts ====================================================== BOINC :: Watchdog shutting down... BOINC :: BOINC support services shutting down... </stderr_txt> <message> <file_xfer_error> <file_name>1n0u__ETABLE_TEST_ABRELAX_rhh13sm6__1452_10_0_0</file_name> <error_code>-161</error_code> </file_xfer_error> </message>
53) Message boards : RALPH@home bug list : Bug reports for Ralph 5.35 (Message 2437) Posted 30 Oct 2006 by zombie67 [MM] Post: Not sticky like the rest of the bug reports? Also, what is the schedule for WU releases?
54) Message boards : RALPH@home bug list : Bug reports for Ralph 5.33 and 5.34 (Message 2418) Posted 21 Oct 2006 by zombie67 [MM] Post: Here's another one.
55) Message boards : Current tests : Are we testing anything over here at the moment ? (Message 2409) Posted 17 Oct 2006 by zombie67 [MM] Post: So....are we testing anything now? If not, when will the next batch of testing happen?
56) Message boards : Current tests : New crediting system (Message 2086) Posted 16 Aug 2006 by zombie67 [MM] Post: Right. My fault for not using the right terminology. So we're on the same page now? Does this mean you agree or disagree with my points? Basically I'm agree with Ethan's viewpoint. What does that mean in plain english? Could you be more vague? My point in this part of the discussion (that you objected to) was: "In fact, I am a huge fan of the way SETI is doing it. And optomized clients mean exactly that...they crunch the SAME job in less time. More work = more credit = more science! Who can argue with that?" So replace OC with SA to correct my language isssue. Do you still object?
57) Message boards : Current tests : New crediting system (Message 2083) Posted 16 Aug 2006 by zombie67 [MM] Post: I mean that with SETI, they have optomized science applications (in your terminology). These "applications" are machine specific. They actually improve the efficiency of the machines. http://ralph.bakerlab.org/forum_reply.php?thread=233&post=2081#2074 the term "science application" is widely used eg http://en.wikipedia.org/wiki/BOINC Right. My fault for not using the right terminology. So we're on the same page now? Does this mean you agree or disagree with my points?
58) Message boards : Current tests : New crediting system (Message 2081) Posted 16 Aug 2006 by zombie67 [MM] Post: No. You are wrong. Witht with SETI (and Einstein too if I understand correctly) the optomized clients actually do the job faster because they are optomized for the machine architecture. I know this for a fact for SETI and Macs. It is you that are wrong. What really compute is the science application. The client is just a manager. Good lord. "What we have here is a failure to commuicate." We have a terminology fubar. I mean that with SETI, they have optomized science applications (in your terminology). These "applications" are machine specific. They actually improve the efficiency of the machines. Clear as mud?
59) Message boards : Current tests : New crediting system (Message 2080) Posted 16 Aug 2006 by zombie67 [MM] Post: The claims aren't false and therefore are not illegal. We have ALL read the posts from the admins, over and over, that optomized clients are not illegal/baned/against the rules/whatever. Change the rules....Good! But don't punish people for not breaking the rules. I'm not suggesting the science claims are false, there hasn't been a case of that happening I'm aware of. I'm only suggesting the credit claim needs to be re-evaluated. It's not a matter of optimized or standard client scores. . it's a matter of work done for the project. If you have the most uber quad core overclocked liquid nitrogen powered rig dedicated 100 percent to Rosetta, you should be at the top of the leader board. . . you shouldn't be there just because you could edit a text file to add a couple zeros to your flops count. You are suggesting to change the rules, after people have already invested their machines' time based on rules at the time the joined. How will you pay them back for that time?
60) Message boards : Current tests : New crediting system (Message 2075) Posted 16 Aug 2006 by zombie67 [MM] Post: ... I'm not sure I understand your point. I think you are saying "But it should be okay to change the rules going forward, right?" If so, I agree 100%. In fact, I am a huge fan of the way SETI is doing it. And optomized clients mean exactly that...they crunch the SAME job in less time. More work = more credit = more science! Who can argue with that? I think your argument is based on a misunderstanding - An optimised client (i.e., a drop-in replacement manager) does no more science work than the original manager it replaced. No. You are wrong. Witht with SETI (and Einstein too if I understand correctly) the optomized clients actually do the job faster because they are optomized for the machine architecture. I know this for a fact for SETI and Macs. Edit: I have seen the time get smaller for the same job, using optomized mac client. This is not replacing the boincmgr, but instead the acutal client. http://tbp.berkeley.edu/~alexkan/seti/

Previous 20 · Next 20