What's the fascination with a 64bit application?

A lot of linux distros abandoned 32 bit support.
Windows is slowly abandoning 32 bit support.
So, migrating to 64 bit is a natural way.

(For example they have not to debug 32 and 64 bit, but only one).
A wrapper is ever an annoyning thing
About SSE/AVX i see you're new here, it's a long and sad story.

If you see, the COVID-19 wus use 2gb of ram or more.
Maybe in the future we will have simulations that will use 4gb of ram each (i hope that, if it occurs, we can select these in our user profile)

---

I am still running my original projects. Seti.Milkyway.Einstein and GPUGrid. I was reduced to only running one of my gpus when I didn't have enough memory to run the 6 Rosetta tasks when I only had 16GB in the host.

Kept getting out of memory error messages in the log and only one gpu running.

Adding the extra 16GB allowed me to regain my gpu work and also get 12 Rosetta tasks running.

Heretical post coming up:
While I'm conscious of how much Seti has led to the development of the entire Boinc platform, it should now be obvious, to the point of being unarguable, that every single second anyone spends running Seti is a waste of timeelectricityeverythinganything, so if you were to NNT Seti now and forever more, you could abort any remaining Seti tasks and divert your considerable resources to something better, especially your current buffer.

That applies to everyone. Nothing riles me up more than the Seti project continuing to exist, irrespective of its historical benefits to Boinc development. It is pure BS.

---

Yes, I am branding you a heretic.

You got your wish, the Seti project ends Wednesday. That is why Folding@home, Rosetta@home and GPUGrid projects have had such an influx of new volunteers in the last month since the shutdown was announced.

A lot of linux distros abandoned 32 bit support.
Windows is slowly abandoning 32 bit support.
So, migrating to 64 bit is a natural way.

(For example they have not to debug 32 and 64 bit, but only one).
A wrapper is ever an annoyning thing

OK, but why is it annoying?
It allows 64bit systems that can't deal with 32bit software to run it. Minimal performance penalty, if any. No developer time needed to fully rewrite the application, test, debug, test, debug, test etc.
Why spend time, money & effort to do something that provides no benefit at all over what already exists?

---

Grant
Darwin NT

to the point of being unarguable, that every single second anyone spends running Seti is a waste of timeelectricityeverythinganything, so if you were to NNT Seti now and forever more, you could abort any remaining Seti tasks and divert your considerable resources to something better, especially your current buffer.

Good science is never a waste of time.

---

Grant
Darwin NT

Yes, I am branding you a heretic.

You got your wish, the Seti project ends Wednesday. That is why Folding@home, Rosetta@home and GPUGrid projects have had such an influx of new volunteers in the last month since the shutdown was announced.

Such are my powers of persuasion. Yesssss!
I thought that's what I heard was happening, but I try not to count chickens until they're hatched. A <great> day is coming.
(You may as well abort any of those tasks now they're even more worthless, obviously. Kill it with fire)

---

every single second anyone spends running Seti is a waste of time/electricity/everything/anything, so if you were to NNT Seti now and forever more, you could abort any remaining Seti tasks and divert your considerable resources to something better, especially your current buffer.

Good science is never a waste of time.

100% agreed.
Also, BS is always BS

---

My opinion of any of the math problem projects is the same as yours of SETI. Pure BS. I will never crunch just to some find some bajillion factored prime number or prove some long forgotten math theoretical hypothesis.

I will crunch for some hard science astronomy, physics or biological project when SETI goes on hiatus.

My opinion of any of the math problem projects is the same as yours of SETI. Pure BS. I will never crunch just to some find some bajillion factored prime number or prove some long forgotten math theoretical hypothesis.

I will crunch for some hard science astronomy, physics or biological project when SETI goes on hiatus.

Did someone say Chess openings? Everyone has their own 'thing'.
What did it for me (and I may have this wrong but I hardly needed an excuse in the first place) is I heard Seti found precisely nothing, but seeing as they had nothing else to examine they decided to put all the same tasks out again in order to confirm the nothing they found. I don't even care if that isn't true...

---

I don't even care if that isn't true...

Nope. Not true. They haven't analyzed ANY of the 20 years of observations. Yet. That is why they are going on hiatus to start the analysis and write the papers. They tried a real-time analysis a few years ago and found they didn't have the hardware powerful enough to do so.

They have a new backend analysis profiler called Nebula they have been trying to do machine learning on the data and processing it over on the Atlas supercomputer at Einstein.org.

They have rerun older data through the pipeline several times because they have kept improving the search sensitivity over many iterations of the science apps.

But they are running new data from the GBT telescope through for the past couple of years. Files recorded just this past week in fact. It is a shame we never got to look through the data that was going to come from the Parkes array in Australia as that is a completely different direction in the sky. A more interesting one in my opinion, that would have listened on the galactic center where I think ET is hanging out.

I don't even care if that isn't true...

Nope. Not true.

...

---

So does the Rosetta scheduler settle on the app that has the highest APR here like other projects?

The 4.07 app is running a higher APR than the 4.08 and that seems contrary to most of the hosts that I have looked at that run only 4.08 tasks.

As recent admin posts have pointed out, specific versions are required to use specific protocols (methods of searching the protein energy landscape). So it just depends which work unit gets assigned to a given host.

I don't recall the APR acronym, and get a boatload of hits referring to April. So perhaps I missed the question.

---

Rosetta Moderator: Mod.Sense

I don't recall the APR acronym, and get a boatload of hits referring to April. So perhaps I missed the question.

APR Average Processing Rate.
Computer details, Application details. Average Processing Rate in FLOPs.
eg- for my system-

Rosetta Mini 3.78 windows_x86_64    Average processing rate	2.80 GFLOPS
Rosetta Mini 3.78 windows_intelx86  Average processing rate	2.80 GFLOPS


Rosetta 4.07 windows_intelx86       Average processing rate	3.02 GFLOPS
Rosetta 4.07 windows_x86_64         Average processing rate	3.07 GFLOPS

Rosetta 4.12 windows_intelx86   no APR (no work has been done using this application yet).

It is an indicator of how well an application performs. The more Floating point Operations it can do each second, the more work it can do each second & the better it is.

You have 2 Rosetta Mini applications and 2 Rosetta applications.

Rosetta Mini 3.78 windows_x86_64
Rosetta Mini 3.78 windows_intelx86

Rosetta 4.07 windows_intelx86
Rosetta 4.07 windows_x86_64

If the Rosetta Mini 3.78 applications (_x86_64 and _intelx86) both process the same Tasks, then the BOINC manager will allocate work to each application and as results are returned & verified the APR will settle down. The apllication with the highest APR will be considered the best one to use, and in the future all new work will be sent to be processed by that application.
Likewise for Rosetta 4.07 applications.


In the case of Seti, some hardware had as many as 4 different versions of an application to choose from. Depending on the supported instruction set & architecture of the hardware, different applications performed better on different models. The BOINC Manager would allocate Tasks to each application and as APRs for each application stabilised it would then eventually use the best (fastest) application from then on.

---

Grant
Darwin NT

Yes, Average or Application Processing Rate = APR.

Currently this is how my host is performing:

Rosetta 4.07 i686-pc-linux-gnu: 3.21 GFLOPS

Rosetta 4.08 x86_64-pc-linux-gnu: 3.04 GFLOPS

Turnaround time is almost exactly equal between the two apps. 1.29 days vs 1.28 days.

Turnaround time is almost exactly equal between the two apps. 1.29 days vs 1.28 days.

That's just the nature of Rosetta tasks. There is no end to a task, other than the nominated time to process it for. A 20 year old CPU, or the latest and greatest CPU given a particular Task will run it for the same time (if they both have the same "Target CPU run time" selected in their project preferences).
Of course the latest & greatest will do the most amount of work during that period (number of Attempts & number of Decoys), and should have a higher APR to show for it.

---

Grant
Darwin NT

Turnaround time is almost exactly equal between the two apps. 1.29 days vs 1.28 days.

That's just the nature of Rosetta tasks. There is no end to a task, other than the nominated time to process it for. A 20 year old CPU, or the latest and greatest CPU given a particular Task will run it for the same time (if they both have the same "Target CPU run time" selected in their project preferences).
Of course the latest & greatest will do the most amount of work during that period (number of Attempts & number of Decoys), and should have a higher APR to show for it.

Don't know if this is good, bad or unexpected.
======================================================
DONE :: 1 starting structures 28051.2 cpu seconds
This process generated 11 decoys from 11 attempts
======================================================
BOINC :: WS_max 1.12835e+09

What I'd like to find out is the cause of my errored tasks. Nothing in the stderr.txt output indicates any faults or failures. So nothing to go on for troubleshooting.

Looks like some of the problem are signal 11, see this post for info.

---

Rosetta Moderator: Mod.Sense

Looks like some of the problem are signal 11, see this post for info.

That doesn't seem to match my cpu. My cpu is the latest AMD not a very early one.

keith@Serenity:~$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 113
Model name: AMD Ryzen 9 3950X 16-Core Processor
Stepping: 0
CPU MHz: 4200.194
CPU max MHz: 4200.0000
CPU min MHz: 2200.0000
BogoMIPS: 8400.39
Virtualization: AMD-V
L1d cache: 32K
L1i cache: 32K
L2 cache: 512K
L3 cache: 16384K
NUMA node0 CPU(s): 0-31
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca
keith@Serenity:~$

And it does support the SSSE3 SIMD instruction set.

OK, sorry, I didn't have chance to look up the specs.

Please point out the WUs to described where you felt they had problems, but had no errors.

---

Rosetta Moderator: Mod.Sense