|
1)
Message boards :
Number crunching :
Crunching speed
(Message 72641)
Posted 2 Apr 2012 by Allan Hojgaard Post: I have two computers crunching WUs and they are wildly very different: It is indeed a laptop. I should have included that. As for the tweaks and tips I will echo Chilean's request to mikey: Go on... |
|
2)
Message boards :
Number crunching :
Crunching speed
(Message 72635)
Posted 1 Apr 2012 by Allan Hojgaard Post: I have two computers crunching WUs and they are wildly very different: Intel(R) Celeron(R) CPU 430 @ 1.80GHz [Family 6 Model 22 Stepping 1] Intel(R) Core(TM)2 Duo CPU T6500 @ 2.10GHz [Family 6 Model 23 Stepping 10] Despite the large difference in clock speed, cache and other general advances in micro architecture, the Celeron defeats the Core2 Duo in both floating point speed and integer speed! My CPU figures are as follows: ------------------------------------------------------- Celeron*: Measured floating point speed: 1730.06 million ops/sec Measured integer speed: 3711.3 million ops/sec Core2 Duo**: Measured floating point speed: 1205.33 million ops/sec Measured integer speed: 3673.87 million ops/sec ------------------------------------------------------- *Runs on Microsoft Windows XP Professional x86 Edition, Service Pack 3, (05.01.2600.00) **Runs on Microsoft Windows 7 Ultimate x64 Edition, Service Pack 1, (06.01.7601.00) I did not notice this discrepancy until I looked more carefully into the estimated completion time. The Celeron was, on average, taking roughly 6 hours to crunch a WU while the Core2 Duo took about 7 and a half hours on average. To me it seems preposterous! A low budget CPU from Q2 2007 beating a superior CPU from Q2 2009? Can someone tell me if there are any tricks/tweaks I can apply to my Core2 Duo to make it perform better? Which characteristics does Rosetta@Home like in a CPU? Raw clock speed? Lots of Cache? Faster RAM? |
|
3)
Message boards :
Number crunching :
Minirosetta v1.40 bug thread
(Message 56798)
Posted 10 Nov 2008 by Allan Hojgaard Post: Adding my share of long working WUs: 1hzh_2pww_fchbonds_20_30sarel_SAVE_ALL_OUT_4704_86 Result: <core_client_version>6.2.18</core_client_version> <![CDATA[ <stderr_txt> # cpu_run_time_pref: 21600 # cpu_run_time_pref: 21600 ====================================================== DONE :: 1 starting structures 39652.9 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> ]]> As many have said before I do not mind crunching large WUs, but I would like to be credited/warned about it beforehand. Currently one of my cores is working on 1hzh_1a58_fchbonds_20_30sarel_SAVE_ALL_OUT_4704_87_0 and it has now been working on it for 14 hours and 24 minutes and it has reached 98.840%. I am sure that I will get very low credit for it like the others in this thread. This what the graphics show me: http://www.home.no/kalumba/rosetta.png Until the mess has been sorted out/properly explained I'm crunching for another project. I'm going to visit the forum frequently as Rosetta@Home is my favourite project. |
|
4)
Message boards :
Number crunching :
Optimized Rosetta
(Message 55622)
Posted 8 Sep 2008 by Allan Hojgaard Post: Yes Allan, the complexity of the tasks is identical, but your machine will spend more (or less) time creating models, and therefore create more (or less) models for that task. This is why credit is based on work completed. It gives everyone the flexibility to spend an amount of time on tasks that is comfortable for their environment. I see. So the system works like this: All WUs need 1 day of processing (judging from the Rosetta preferences) and what I am currently doing is crunching 3 hours worth of it. Then it gets sent to another computer for anywhere from 1 hour to 21 hours until it is completed? And should I decide to take the full day processing then I would get an enormous amount of credits in exchange for my patience as well as a bigger chance of becoming "Predictor of the day"? |
|
5)
Message boards :
Number crunching :
Optimized Rosetta
(Message 55553)
Posted 5 Sep 2008 by Allan Hojgaard Post: Since default is 3 hours does that mean that if I set it higher the client asks for more advanced WUs or spends more time looking for models in a WU? |
|
6)
Message boards :
Number crunching :
Optimized Rosetta
(Message 55542)
Posted 4 Sep 2008 by Allan Hojgaard Post: I am more interested in seeing improvements in speed for the Linux client. I am running a Core2 T7300 @ 2.0 GHz (Ubuntu 8.04) and its average time to crunch a WU is about 10.000 seconds while another computer of mine, a rather lowly AMD Sempron 3000+ (WinXP) takes on average about 8.000 seconds. Sure I get more credits, but I am more interested in how many WUs I can crunch than points (Science over personal gains) so it feels strange that there is no more optimization to be done on the client when the WinXP client can out crunch a Linux client running on a faster CPU. Are you absolutely sure there is no room for a SSE, MMX, 3DNOW, Enhanced 3DNow!, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, SSE4a and the upcoming SSE5 and AVX from AMD and Intel respectively? Perhaps some other tweaks to make the Linux client run faster? |
|
7)
Message boards :
Number crunching :
Problems with version 5.96
(Message 53820)
Posted 19 Jun 2008 by Allan Hojgaard Post: Yet another WU that takes roughly 3 hours to crunch, gets stuck at 100% and doesn't actually finish. Roughly 3 hours wasted again. I am going to crunch WUs for Spinhenge@home until the matter has been resolved. I am also going to periodically check this thread and the main page for updates on this issue. Please fix this issue quickly because so far Rosetta@Home is my favorite distributed computing project. |
|
8)
Message boards :
Number crunching :
Problems with version 5.96
(Message 53815)
Posted 19 Jun 2008 by Allan Hojgaard Post: These 3 WUs showed the same behavior as the 3 other WUs I reported earlier, but since I I can not find my post in this thread I will report it again and add these 3 to the list: The latest: t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_65018_0 t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_74793_0 t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_77384_0 The previous: t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_10358_0 t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_28688_0 t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_38843_0 What happens is that these WU reach 100%, but do not use any CPU power at all. BOINC still reports these as running and does not release/report/abort them so one of my cores sits idly by and does nothing. The only solution is to manually abort the WUs and let BOINC take the next one. This is very annoying as I could be crunching WUs with all that idle time instead having my other core waiting indefinitely for an already finished WU. Laptop specs: Ubuntu Linux 8.04 (2.6.24-19-generic kernel) BOINC 5.10.45 Intel Core 2 Duo T7300 @ 2GHz 2GB RAM I would like to hear a response or workaround from the developers or forum administrators so that I, and surely many others, can better navigate the beta pitfalls and spend more time crunching and less time not crunching. |
|
9)
Message boards :
Number crunching :
Problems with version 5.96
(Message 53727)
Posted 16 Jun 2008 by Allan Hojgaard Post: Here are my problems with the 5.96 beta version: WU 156587340: t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_38843_0 WU 156567311: t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_28688_0 WU 156416544: t405__CASP8_JUMPAB_RES81to192_SAVE_ALL_OUT_BARCODE__3758_10358_0 Those WUs were all completed (100%), but BOINC still listed them as running and the processes were not consuming any CPU %. I had to abort them in order for BOINC to pick the next WUs in line. All 3 had Exit status -197 (0xffffff3b). Zero credit received. I am using BOINC 5.10.45 on Ubuntu 8.04 with an Intel Core2 Duo T7300 @ 2GHz in an Mobile IntelĀ® 965 Express Chipset with 2GB of RAM. |
©2026 University of Washington
https://www.bakerlab.org