Posts by William Albert

1) Message boards : Cafe Rosetta : something broke (Message 97439) Posted 17 Jun 2020 by William Albert Post: i've been running rosetta for years on a mac mini w/macos 10.7, until the switch to ssl. i switched the url (trivial), deleted and re-added rosetta, and i think i updated to a newer version of boic. and now all of a sudden i get a "computing error" on every single work unit, with 0 cpu time used. what broke? You have a "Signal 11" error for every work unit, that's on your end "signal 11, or translated a segmentation error pointing to a problem with your memory, virtual memory (page file) or that it's a bad batch of tasks. However, if you're the only one returning these as an error and consistently over two or more projects, you best go look into a problem with the RAM or page file on that computer" While a segfault can be caused by faulty hardware, WU's consistently segfaulting right away with no CPU time used points to a software problem.
2) Message boards : Number crunching : Waiting for Memory (Message 97235) Posted 5 Jun 2020 by William Albert Post: If your computer only has 2GB of RAM, I would not attach it to the Rosetta@home project, as many WUs will use 1+ GB of RAM. Even if you could get the WUs to run, they would frequently be hitting swap, and it's unlikely that you would generate a quality result. It would be cool if Rosetta@home would partition its application into low- and high-memory variants, so that the many machines without the memory to crunch the bigger WUs can still participate (and conversely, the machines with large amounts of memory can focus on the larger WUs). I'm not sure if that would be feasible, but just throwing the idea out there.
3) Message boards : Number crunching : Large numbers of tasks aborted by project killing CPU performance (Message 97208) Posted 4 Jun 2020 by William Albert Post: Continued whining from shanen about how crappy Rosetta@home is, how bad the people who run it are, and how everyone is wrong except for him. Not only has Rosetta@home generally managed the influx of new users well given their resources, but Rosetta@home easily has the most predictable WU runtime of any BOINC project I've run, because you can literally set what that runtime is. The setting is located in your Rosetta@home account, under Preferences > Rosetta@home preferences > Target CPU run time. This combined with the caching options that BOINC provides (which numerous people in this thread have pointed you to, repeatedly) means that you can predict almost exactly what the turnaround time for a Rosetta@home WU will be. Things get a bit more complicated if the computer isn't crunching for Rosetta@home 100% of the time, but you can compensate for this by reducing the "Target CPU run time" accordingly (e.g., setting it to 2 hours, down from the default of 8 hours). The 3-day deadline is set as such by the project administrators because it allows researchers to get quick feedback on their work units, and it helps to mitigate the negative effects of slow or unreliable hosts. It can also reduce storage requirements, as WUs that are completed and validated can be removed more quickly to make room for other WUs. The cost to short deadlines is increased network load on the infrastructure to deal with WU timeouts and retransmissions, but given that the deadlines have shortened as Rosetta@home's computing power has increased, the project administrators have clearly found the benefits to be worth the cost. In any case, Rosetta@home provides very fine grained control over how long a WU will execute and how many queued WUs you keep. Having to abandon work because you have more queued WU's than you can complete by the deadline is a problem ENTIRELY of your own making. If, for whatever reason, you cannot overcome this issue (even though Rosetta@home seemingly works for hundreds of thousands of other volunteers), perhaps that's a sign that Rosetta@home isn't the right project for you? There are many other BOINC projects that have shorter run times, longer deadlines, and could potentially use your computing power. Maybe you should give World Community Grid or Ibercivis a try?
4) Message boards : Number crunching : Rosetta running on ARM platforms (Message 96591) Posted 17 May 2020 by William Albert Post: I don't think Windows 10 on Arm is a supported platform (or ever will be). The hardware itself is compatible with Rosetta@home, but only if you somehow run it on Linux in a virtual machine. I dont own one, I was just curious whether it could run Boinc projects like it does some other x86 software. It might be able to emulate the 32-bit Rosetta for Windows, but the performance would be complete trash and not worth the effort.
5) Message boards : Number crunching : Rosetta running on ARM platforms (Message 96588) Posted 17 May 2020 by William Albert Post: Is it possible to run Rosetta (or Boinc projects in general) on Windows 10 on ARM? I don't think Windows 10 on Arm is a supported platform (or ever will be). The hardware itself is compatible with Rosetta@home, but only if you somehow run it on Linux in a virtual machine.
6) Message boards : Number crunching : Time to drop 32 bit OS? (Message 96559) Posted 16 May 2020 by William Albert Post: My Pentium laptop is 32 bit so if Rosetta went just 64 bit, my laptop would have nothing to do. Being as old as it is and still running Win 7 Pro 32 bit, I have no idea about how I could re-purpose it. Sure, I'm sure that someone would say, "just find a project that still uses 32 bit apps", but I have no real interest in anything else. I have an Intel x86 Tablet PC running Ubuntu Linux. It's still perfectly functional, but since Rosetta@home WUs run for a fixed period of time, rather than processing a fixed amount of work, I was concerned that this machine wasn't providing as high-quality a result as much more powerful machines would if they had the WU instead. Ultimately, I decided to pull my Tablet PC and a handful of other weaker machines off of Rosetta@home, and have them crunching for other projects instead (currently WCG OpenPandemics and Ibercivis). I still keep them on ralph@home to make them available for testing. At this point, x86 machines are obsolete. Even the processors in my mobile phone are more powerful than the fastest 32-bit Intel or AMD processors. I've been toying with the idea of moving my x86 machine to a support role (monitoring, PXE boot, shared NFS storage, etc.), but given that Linux distros are completely dropping support for x86, I'll probably just retire it.
7) Message boards : Number crunching : Rosetta now abandonware? (Message 96496) Posted 14 May 2020 by William Albert Post: The Rosetta@home project is still active, work is being produced and accepted in a timely manner, and the project admins and moderators are active on the forums. Ralph@home is where Rosetta@home's project development and early testing happens, so you may want to follow that project if regular project communication is important to you. In terms of science, Rosetta tends to announce results on their Twitter account first, so you may want to follow that. Not all workloads are amenable to GPU or SIMD support, and adding that capability takes development time and effort. The project admins have commented on this multiple times in the past, stating that GPUs aren't suitable for the type of work that Rosetta@home currently does. Perhaps that will change in the future, but as for now, Rosetta@home is not the right project for you if your require GPU support. Some work units may have bugs. It happens, and they get corrected and the work re-issued. If you're seeing BSODs or kernel panics, chances are your hardware is unstable. The priority for many of these projects is first and foremost the science (or whatever work is being done). While it would be nice to get more frequent updates, the researchers and project admins still have to do their day jobs, and the more time that they spend on community engagement, the less time they have to handle the actual project work. Given that balance, I find the admin's community participation to be reasonable.
8) Message boards : Number crunching : How secure is my machine when running R@h? (Message 96409) Posted 12 May 2020 by William Albert Post: Is anyone aware of companies that install BOINC to run R@H out of office hours in their main office desktops or data-centers spare capacity? or, as the name would say, this is only meant for home usage? We utilize some of our otherwise-unused data center capacity for BOINC projects like Rosetta, but machines used for this purpose are dedicated toward it; we don't mix BOINC and non-BOINC workloads on the same machine. We also take other hardening steps, like secure erasing disks before being used in machines that run BOINC, and keeping BOINC machines outside of our internal production networks. That being said, I wouldn't recommend using shared office PCs for BOINC, for security and performance reasons.
9) Message boards : Number crunching : How secure is my machine when running R@h? (Message 96319) Posted 10 May 2020 by William Albert Post: One method to assure that a BOINC project cannot modify anything outside of the scope of the project on your machine is to run BOINC in a sandbox. While account sandboxing is a great feature, and can be used without downsides on most platforms, it should be noted that sandboxing on Windows prevents BOINC from using the GPU.
10) Message boards : Number crunching : Quite a few signal 11 errors on a Linux host - what does it mean? (Message 96117) Posted 5 May 2020 by William Albert Post: Looks like this is your host in question: https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=4295358 Your computer is running an AMD Opteron 6128 HE, which is based on the AMD K10 architecture. AMD K10-based processors have a known issue with Rosetta on Linux where the application assumes that the SSSE3 instruction is present, which it is not for AMD K10. See this bug report for more details. Hopefully this will be fixed soon. Until then, I would recommend either running Windows (which doesn't have this problem), or using this machine for other projects that you might be interested it.
11) Message boards : Number crunching : Threadripper and Ryzen (and EYPC) (Message 95902) Posted 3 May 2020 by William Albert Post: I know the performance is in the Ryzen 3700x etc, however how does the Ryzen 5 3400G compare these days? Especially in performance. Many BOINC project sites have a CPU statistics page where you can see how the various CPUs running project workloads compare. Here's a link to Rosetta@home's: https://boinc.bakerlab.org/rosetta/cpu_list.php Assuming that you're using 100% of your available threads, the Ryzen 5 3400G can do about 40 GFLOPS, whereas an FX-8350 can do about 26 GFLOPS. That would make the 3400G almost twice as fast, assuming that both processors are running at stock speeds.
12) Message boards : Cafe Rosetta : internet requirements? (Message 95027) Posted 21 Apr 2020 by William Albert Post: Based on what a machine I spot-checked is currently doing, most of the work units are less than a megabyte. Here's a quick file listing of the Rosetta directory: 485M database_357d5d93529_n_methyl.zip 68K Helvetica.txf 5.8M hgfp_split2_460_data.zip 348K LiberationSans-Regular.ttf 110M minirosetta_3.78_x86_64-pc-linux-gnu 270M minirosetta_database_d0bf94b.zip 47M minirosetta_graphics_3.78_x86_64-pc-linux-gnu 176K pass_build.bp_20200412145206_perturb_2790_0001_0001_fragments_data.zip 184K pass_build.bp_20200412145353_perturb_4974_0001_0001_fragments_data.zip 184K pass_build.bp_20200412145841_perturb_2744_0001_0001_fragments_data.zip 180K r3x_1541_data.zip 172K r3x_5760_data.zip 172K r3x_5901_data.zip 172K r4d_1164_data.zip 180K r4k_11075_data.zip 176K r4k_12609_data.zip 180K r4k_15519_data.zip 176K r4k_17413_data.zip 180K r4k_6123_data.zip 176K r4k_6474_data.zip 64K rb_04_19_21998_21765_ab_t000__h002_robetta.200.18mers.index.gz 88K rb_04_19_21998_21765_ab_t000__h002_robetta.200.3mers.index.gz 76K rb_04_19_21998_21765_ab_t000__h002_robetta.200.8mers.index.gz 4.0K rb_04_19_21998_21765_ab_t000__h002_robetta_FLAGS 4.0K rb_04_19_21998_21765_ab_t000__h002_robetta.zip 276K rb_04_19_22030_21740_ab_t000__robetta.200.3mers.index.gz 256K rb_04_19_22030_21740_ab_t000__robetta.200.6mers.index.gz 252K rb_04_19_22030_21740_ab_t000__robetta.200.7mers.index.gz 4.0K rb_04_19_22030_21740_ab_t000__robetta_FLAGS 28K rb_04_19_22030_21740_ab_t000__robetta.zip 76K rb_04_19_22040_21638_ab_t000__h001_robetta.200.10mers.index.gz 88K rb_04_19_22040_21638_ab_t000__h001_robetta.200.3mers.index.gz 84K rb_04_19_22040_21638_ab_t000__h001_robetta.200.5mers.index.gz 4.0K rb_04_19_22040_21638_ab_t000__h001_robetta_FLAGS 4.0K rb_04_19_22040_21638_ab_t000__h001_robetta.zip 232K rb_04_19_22059_21792_ab_t000__h002_robetta.200.3mers.index.gz 220K rb_04_19_22059_21792_ab_t000__h002_robetta.200.6mers.index.gz 216K rb_04_19_22059_21792_ab_t000__h002_robetta.200.7mers.index.gz 4.0K rb_04_19_22059_21792_ab_t000__h002_robetta_FLAGS 8.0K rb_04_19_22059_21792_ab_t000__h002_robetta.zip 120M rosetta_4.15_x86_64-pc-linux-gnu 118M rosetta_graphics_4.15_x86_64-pc-linux-gnu 1.2G total The larger files are application binaries and database files which are downloaded as needed, rather than with every work unit. Also, unlike most projects, Rosetta@home work units execute for a period of time that you specify, rather than for the amount of work required to "complete" the unit. As such, you can reduce bandwidth usage by increasing the runtime length in your profile preferences. Finally, the "Computing preferences" section of you account profile gives you an option to explicitly limit how much total data Rosetta will transfer within a given period of time (e.g., 30 days). If you hit that limit, it won't transfer any more data until the time period rolls over. So in short, you'll be fine. The project welcomes your cycles. :)
13) Message boards : Cafe Rosetta : Record performances with EPYC (Message 94970) Posted 20 Apr 2020 by William Albert Post: The AMD EPYC 7Fx2 series is intended for applications that benefit more from frequency and cache, over raw thread count. However, Rosetta@home is perfectly able to use as many threads as a system has available (provided that the machine has sufficient RAM). While these frequency-optimized SKUs are impressive for their intended workload, they wouldn't be optimal for Rosetta compared to the existing 2nd generation Epyc lineup.
14) Questions and Answers : Unix/Linux : Working Instructions for Installing BOINC Client on new Installation of Ubuntu 18.04.4 LTS (Message 94433) Posted 14 Apr 2020 by William Albert Post: All of my Ubuntu machines are running 18.04.4, and I installed boinc directly from the built-in repos -- no PPAs needed. Granted, most of them are headless machines that aren't running boinc-manager (if I need to see status locally, I SSH in and run boinctui), but I do have a laptop with a full GUI install that is running boinc-manager, and I don't recall having to do anything special to get it working.
15) Questions and Answers : Unix/Linux : Working Instructions for Installing BOINC Client on new Installation of Ubuntu 18.04.4 LTS (Message 94351) Posted 13 Apr 2020 by William Albert Post: sudo apt install boinc ^ That didn't get you up and running?
16) Message boards : Number crunching : Android RAM requirements changed? (Message 93038) Posted 2 Apr 2020 by William Albert Post: Practically all modern smartphones (Android or otherwise) use an ARM-based processor, including the Galaxy S8. You can find what hardware your smartphone uses by searching for the model on Wikipedia. In the case of the Samsung Galaxy S8, the CPU will be either a Samsung Exynos 8895 or a Qualcomm Snapdragon 835, depending on which market you bought it in.
17) Message boards : Number crunching : Android RAM requirements changed? (Message 93030) Posted 2 Apr 2020 by William Albert Post: I have a Google Nexus 6 that had the same issue. I found that by default, BOINC for Android is only permitted to use 50% of the device's memory. By setting it to 100%, I was able to get my devices to accept jobs. The setting can be changed in the BOINC preferences menu on the Android device itself.
18) Message boards : Number crunching : Rosetta x86 on AMD CPU (Message 92961) Posted 1 Apr 2020 by William Albert Post: Looking at one of your work units as an example: <core_client_version>7.17.0</core_client_version> <![CDATA[ <message> process got signal 11</message> <stderr_txt> command: <snipped for brevity> Starting watchdog... Watchdog active. </stderr_txt> ]]> The error is right right near the top: <message> process got signal 11</message> A "Signal 11" is a seg fault.
19) Questions and Answers : Web site : Error message on the info page for one of my computers (Message 92952) Posted 1 Apr 2020 by William Albert Post: When looking at the info page for one of my computers, I'm seeing a consistent PHP error message: Notice: Undefined offset: 2 in /projects/boinc/rosetta/html/inc/host.inc on line 260 Notice: Undefined offset: 3 in /projects/boinc/rosetta/html/inc/host.inc on line 271 I recently installed the AMD ROCm framework so that I could potentially use the computer's GPU for other BOINC projects, and these PHP errors began to appear after my GPU was listed in the computer details (it was absent before). I'm not sure if that's the cause of the problem, but maybe it can help to narrow it down.
20) Message boards : Number crunching : Rosetta x86 on AMD CPU (Message 92950) Posted 1 Apr 2020 by William Albert Post: This WU failed in the manner that shimmerfairy described with a segfault. https://boinc.bakerlab.org/rosetta/result.php?resultid=1136163650 The issue that shimmerfairy described is a compatibility issue specific to a missing SSSE3 instruction on AMD K10 CPUs, and wouldn't occur on your Ryzen machine. Your work units are seg faulting. While in the case of K10, the cause of the seg fault is an invalid CPU instruction, WUs can also seg fault as a result of malfunctioning hardware. If you haven't already done so, I would run some hardware stress tests to verify that the hardware is actually stable.

Next 20