Posts by billy ewell 1931

1) Message boards : Technical News : Due to user feedback and an attempt to reduce the load on our servers, we increased the default target run time from 3 to 6 hours, increased job deadlines to 14 days, and added the target cpu runtime option of 2 days (Message 106255) Posted 21 May 2022 by billy ewell 1931 Post: Frankly I have had it with the Python tasks and the wholesale waste of my computers time. The last two tasks (two of many) I downloaded and processed seemed to do reasonably well until reaching about 25 minutes remaining; And from that point on the time remaining decreased about ONE SECOND for every about180 seconds running. I kept my fingers crossed that somehow the problem would be self resolved and the tasks would be completed on time. No way; hours of processing time wasted and I am disgusted and am going to dismiss myself from Rosetta and await for Tuesday the 24th of May to arrive and hopefully the WCG program now under The University of Toronto will open up the new World Community Grid project with oversight and management by the outstanding team of Kembril people. By the way, I have arrived at the point in my life wherein I can purchase whatever equipment I need to make the greatest contribution to distributed computing and its contribution to the World's Research For Scientific Findings. I would welcome any technical advice about what specific type of computers and Graphics Processing Units I should buy to affect the most good. And this I will say: When Dr. Baker and his team get their act together I will be happy to return to Rosetta and contribute my support with joy and success.
2) Message boards : Technical News : Due to user feedback and an attempt to reduce the load on our servers, we increased the default target run time from 3 to 6 hours, increased job deadlines to 14 days, and added the target cpu runtime option of 2 days (Message 106184) Posted 11 May 2022 by billy ewell 1931 Post: World Community Grid is currently under 24-hour delay. they will get it right!!!
3) Message boards : Technical News : Due to user feedback and an attempt to reduce the load on our servers, we increased the default target run time from 3 to 6 hours, increased job deadlines to 14 days, and added the target cpu runtime option of 2 days (Message 106183) Posted 11 May 2022 by billy ewell 1931 Post: @Falconet: Thank you for the informed and concerning reply. Surely there are currently thousands of hours of perceived computing power going absolutely to waste. I am monitoring World Community Grid which as you and others are aware was fairly recently transferred to the University of TORONTO, and I am convinced that we are going to have some excellent and rewarding scientific work to place on our computers. I am VERY excited about this and I encourage everyone to follow closely the full activation of WCG on Krembil; potentially even as we are communicating now!!!! Bil
4) Message boards : Technical News : Due to user feedback and an attempt to reduce the load on our servers, we increased the default target run time from 3 to 6 hours, increased job deadlines to 14 days, and added the target cpu runtime option of 2 days (Message 106179) Posted 10 May 2022 by billy ewell 1931 Post: It is absolutely beyond my computing intelligence to remotely understand what is going on with the processing of PYTHON tasks.It is inconceivable that 50-51 seconds of computing time is needed to achieve 1 second reduction in time remaining. At that rate of processing virtually over 90% or so of downloaded tasks will be declared "no response" because they exceeded the time limit for reporting. Apparently I will disconnect from Rosetta after I await an overnight response from someone that can enlighten me as to what is the problem Surely I am doing something wrong.
5) Message boards : Number crunching : minirosetta 2.14 (Message 66720) Posted 30 Jun 2010 by billy ewell 1931 Post: billy ewell 1931, thanks for crunching. Regardless of credit granted, the results are valuable. So I cannot agree with your comment about any CPU time being wasted. I would simply say that ideally the runtime per model of these tasks could be more consistent. Rest assured that for every long-running model, there are more credits granted per normal one. This is how the credit system works. Your long-running model result causes the average credit claimed per model to increase, and so as other users report results they (and you) are granted slightly more then if no such long-running model had occurred. The problem is that it is much harder to see that you get a fraction more, and easy to see when you get 50+% less then claimed. Keep crunching. MS: Thanks for the reply; I principally understand but wish to emphasize as I stated previously that "I am not a credits chaser" but a dedicated supporter of scientific research and extremely happy to do so. All that having been said, the work unit recently completed and reported below highlighted my concerns brilliantly. I last checked this work unit at about 6.6 hours of completion time and the last check point at that time was 00:26:13. I started and stopped this unit at least 15 times without effect. My main concern is that my 21 cpus are being used efficiently and your answer has reassured me. Again, thanks. Bill [q] Task ID 349219039 Name fc_A_noSmallMvs_fc6x_2hwx_ProteinInterfaceDesign_20Jun2010_21458_97_0 Workunit 318903612 Created 29 Jun 2010 8:01:24 UTC Sent 29 Jun 2010 8:03:08 UTC Received 30 Jun 2010 18:46:19 UTC Server state Over Outcome Success Client state Done Exit status 0 (0x0) Computer ID 1273687 Report deadline 9 Jul 2010 8:03:08 UTC CPU time 28848.84 stderr out <core_client_version>6.10.56</core_client_version> <![CDATA[ <stderr_txt> [2010- 6-30 3:17: 1:] :: BOINC:: Initializing ... ok. [2010- 6-30 3:17: 1:] :: BOINC :: boinc_init() BOINC:: Setting up shared resources ... ok. BOINC:: Setting up semaphores ... ok. BOINC:: Updating status ... ok. BOINC:: Registering timer callback... ok. BOINC:: Worker initialized successfully. Registering options.. Registered extra options. Initializing broker options ... Registered extra options. Initializing core... Initializing options.... ok Options::initialize() Options::adding_options() Options::initialize() Check specs. Options::initialize() End reached Loaded options.... ok Processed options.... ok Initializing random generators... ok Initialization complete. Initializing options.... ok Options::initialize() Options::adding_options() Options::initialize() Check specs. Options::initialize() End reached Loaded options.... ok Processed options.... ok Initializing random generators... ok Initialization complete. Setting WU description ... Unpacking zip data: ../../projects/boinc.bakerlab.org_rosetta/minirosetta_database_rev36507.zip Setting database description ... Setting up checkpointing ... Setting up graphics native ... BOINC:: Worker startup. Starting watchdog... Watchdog active. # cpu_run_time_pref: 14400 BOINC:: CPU time: 28846.8s, 14400s + 14400s[2010- 6-30 11:27:54:] :: BOINC InternalDecoyCount: 64 ====================================================== DONE :: 2 starting structures 28846.8 cpu seconds This process generated 64 decoys from 64 attempts ====================================================== called boinc_finish </stderr_txt> ]]> Validate state Valid Claimed credit 184.044030472935 Granted credit 16.2806625211898 application version 2.14
6) Message boards : Number crunching : minirosetta 2.14 (Message 66708) Posted 29 Jun 2010 by billy ewell 1931 Post: Task ID 349192260: This is a ProteinDesignInterface unit that consumed 7.5 hours of cpu time on an Intel quad 2.66 with 4 gigs of memory. There were 98 starting structures, 98 attempts and 98 decoys resulting. It really irritates me to see the scoring results when a claimed credit amount of 130.12 was reduced to a granted amount of 36.82. This seems to be quite a COMMON result when processing the PDI work units. I am NOT a points chaser but a dedicated supporter of research science and its potential impace for mankind and the world. BUT I still wonder if perhaps 10% or more of my fairly high-quality computing power is going to waste. Three of my computers; an i7 930 and two 9400 2.66 quads were purchased and run 24/7 solely in support of projects like rosetta and other BOINC research initiatives. Am I terribly wrong here or do I have a legitimate concern as a dedicated and loyal supporter of Rosetta and the current CASP? My account is 160868 I appreciate so very much the dedicated professional designers of this project and the loyal crunchers who particularly make it possible. Bill: Austin, Texas USA
7) Message boards : Number crunching : Report long-running models here (Message 66568) Posted 13 Jun 2010 by billy ewell 1931 Post: 313189623: This Work Unit was aborted at the 10.5 hour elapsed point, with about 44+% progress and the time to completion of about 9.5 hours and increasing. Windows Vista 32bit/Intel Q9400 @ 2.66 Ghz. Acct. # 160868. Computers uncovered.
8) Message boards : Rosetta@home Science : CASP9 (Message 66100) Posted 13 May 2010 by billy ewell 1931 Post: That is one hell of a fine post Sid; great job.
9) Message boards : Rosetta@home Science : CASP9 (Message 66097) Posted 12 May 2010 by billy ewell 1931 Post: Based on my reading and interpretation of the preceding posts, I am resetting my account "Computing Preferences" to "0" for the option that says: "Maintain enough work for an additional _______days". My previous setting was 1.5 days so to hopefully guarantee my computers would not be deprived of work during server down-times; and in so doing I was unknowingly guaranteeing that many of my random casp9 units would exceed the 18-hour time restraint from download to upload. Secondly; wouldn't it be practical for admin to post clear casp9 processing time limitations to the Home news section. I appreciate the feedback from the previous posters.
10) Message boards : Rosetta@home Science : CASP9 (Message 66010) Posted 6 May 2010 by billy ewell 1931 Post: Are we now operating in a primarily CASP9 mode? I have over 220 work tasks queued-up in direct support of R@H and to be crunched by my 20+ cpus but I cannot tell from reviewing the tasks if they are CASP related. I feel very strongly about the efforts of this research program and I intend to fully support the scientific effort with all my resources for the indefinite future. Thanks to David and Mike and all other operatives who make this project posssible. Bill
11) Message boards : Number crunching : Amd dual vs quad core (Message 56642) Posted 2 Nov 2008 by billy ewell 1931 Post: Danny&Steven; Thanks much for the information; most helpful. Bill
12) Message boards : Number crunching : Amd dual vs quad core (Message 56632) Posted 2 Nov 2008 by billy ewell 1931 Post: Good information in this thread; thanks. I am interested in a new machine dedicated to BOINC, powered by a quad core and I have definitely noticed a direct correlation between processing speed/time to complete a task and "floating point" and "integer speeds. And yet I have seen no reference to floating point or integer in advertising for any CPU. Am I correct that I should definitely acquire a machine with the highest floating point/integer speeds in order to sharply reduce the time required to complete a task? EXAMPLE: Intel 2.66ghz machines; one with say 1300 floating point and 2900 integer speeds will require perhaps 40% or more time to complete identical tasks than the same 2.66ghz with say 2300 floating point and 5000 integer speeds. Any ideas? Bill
13) Message boards : Number crunching : Minirosetta v1.39 bug thread (Message 56611) Posted 1 Nov 2008 by billy ewell 1931 Post: Beginning 31 October 20:35 UTC and continuing, every work unit with the application "Rosetta Mini with new score terms" has errored out after less than one second of cpu time. Over 20 work units involved. Work units with the application "Rosetta Mini" are computing without error; approximately 20 units. Obviously there is a problem, unfortunately. Access my account in any way you wish to evaluate the problem(s). Bill
14) Message boards : Number crunching : Problems with Rosetta version 5.98 (Message 54157) Posted 3 Jul 2008 by billy ewell 1931 Post: Three work units failed in sequence between 01:19 and 01:43 on 3 July UTC time. The error messages attributed "file transfer error". Apparently over 9 hours of cpu time lost. The WUIDs are: 159628332, 159620771 and 159639505. I have no idea if 5.98 is the culprit but I doubt it as many other units have completed ok as I have been running 4 cpus 100% Rosetta for 68.5 hours straight.