I stopped running Rosetta many months ago when I bought an i7. Problem was that he grabbed all eight CPUs and the fan noise was unacceptable. I did try Tthrottle but that affected all CPUs and my normal work was downgraded significantly.

Is there a way to assign n CPUs to Rosetta where n = Fan Noise OK?

Thanks, Tom

Create an empty text file in the folder for this project and paste the following into the file and save it named as app_config.xml, change the number in max concurrent to the number of cores you want, then stop the client and start the client again or under Options in the Advanced View click Read config files to make it work.

<app_config>
<app>
<name>minirosetta</name>
<max_concurrent>1</max_concurrent>
</app>
</app_config>

You know, that you answered to a over 3.5 years old post of an inactive user?

---

.

I stopped running Rosetta many months ago when I bought an i7. Problem was that he grabbed all eight CPUs and the fan noise was unacceptable. I did try Tthrottle but that affected all CPUs and my normal work was downgraded significantly.

Is there a way to assign n CPUs to Rosetta where n = Fan Noise OK?

Thanks, Tom

this is a very old post and it seemed the 'demon' has gone away for some time and apparently it 'resurfaced' with vengence
the more recent i'd think 4.x versions of rosetta@home it seemed has been pretty 'optimised'
so if you have a haswell and higher cpu (including the amd ryzens) it probably use AVX etc (it is a good thing :)
and probably gets higher compute throughput

the thing is running 8 concurrent threads with AVX/AVX2 switches on perhaps many more transistors concurrently
so this time round the cpu runs *hot* - it is expected really, troughput probably doubled if all that transistors are switched on for maximum performance and try to imagine concurrent avx/avx2 on the high end intel 16-32 cores or ryzen 16-128 cores cpus
ok above is actually off-topic, the topic is really *fan noise*

what i did *in linux* is to make an attempt to *limit the max cpu frequency* while running all 8 threads concurrently e.g.

cpupower -c all frequency-set -u 3.5ghz

on windows some utility may be necessary to limit the max cpu speeds/frequency, i'm not too sure what may help

i try to find the frequencies (cpu speeds) in which the fan runs fast but just a little slow enough to be somewhat quiet

accordingly i think cpu frequencies and cpu core voltages are somewhat related, if you limit cpu frequencies., i think the on-chip or on-board DVFS (dynamic voltage and frequency scaling) circuits would choose a lower core voltage, as power = V^2 / R plus a linear contribution from F (frequency), a tiny change in V and F could significantly reduce power output and hence requires a lower fan speed to keep TDP, temperatures in control

and oh yes get a better 'cpu cooler' with a bigger fan e.g.. 120-140mm fans, the 'tower heatpipes types' they seem to run more silently

that seem to work for me

off-topic:
i think we've very much entered the age of dark silicon
http://darksilicon.org/
on a 16, 32, 64, 128 core/hyperthreads single chip SOC processor, if you try to push 5 Ghz and AVX2 or AVX512 on all 16, 32, 64, 128 cores /hyperthreads, you would probably need absolute zero (-273 deg C) and superconducting silicon to keep the cpu going lol

Random question but couldn’t this be used to create an immortal human, having access to all these new protein configurations?

How do I interpret the server status page?
Today it says "Total queued jobs: 431,868"

For most projects one job is one work unit, but here we have variable work unit sizes creating multiple models apiece.
My 36 hour work units have hundreds of models, and the beta ones have thousands.

The lowest common denominator is a two-hour work unit.
So are the total queued jobs 863,736 hours of work?
Are they 431,868 models of various complexity, completed in minutes to hours apiece?
Are they part of a pool with the in-progress models, totaling 717,885 iterative calculations bouncing between users until they reach a undisclosed limit and retire out of the pool?

How do I interpret the server status page?
Today it says "Total queued jobs: 431,868"

For most projects one job is one work unit, but here we have variable work unit sizes creating multiple models apiece.
My 36 hour work units have hundreds of models, and the beta ones have thousands.

The lowest common denominator is a two-hour work unit.
So are the total queued jobs 863,736 hours of work?
Are they 431,868 models of various complexity, completed in minutes to hours apiece?
Are they part of a pool with the in-progress models, totaling 717,885 iterative calculations bouncing between users until they reach a undisclosed limit and retire out of the pool?

Each WU will work either until it has completed or until the end of the iteration that takes it closest to your requested run time.

If you have set 36 hours as your run time it will run for 36 hours but it is the same WU that would run for 8 hours on another box with the default setup.

How do I interpret the server status page?
Today it says "Total queued jobs: 431,868"

For most projects one job is one work unit, but here we have variable work unit sizes creating multiple models apiece.
My 36 hour work units have hundreds of models, and the beta ones have thousands.

The lowest common denominator is a two-hour work unit.
So are the total queued jobs 863,736 hours of work?

For that you look at the "Successes last 24h" number, which is currently around 381,000- so a bit under 16,000 being returned every hour or so.

---

Grant
Darwin NT

I'm sorry, but neither answer directly responds to my question.

Maybe my question wasn't clear enough, but I'm asking the meaning of TQJ given the variable sizes, not what a work unit is or how long the server will take to process work units.

I'm sorry, but neither answer directly responds to my question.

Maybe my question wasn't clear enough, but I'm asking the meaning of TQJ given the variable sizes, not what a work unit is or how long the server will take to process work units.

TQJ is just that, the total number of Queued jobs
ie the total number of Tasks waiting to be sent out- the size of the file or how long it takes to process is meaningless.

---

Grant
Darwin NT

I'm sorry, but neither answer directly responds to my question.

Maybe my question wasn't clear enough, but I'm asking the meaning of TQJ given the variable sizes, not what a work unit is or how long the server will take to process work units.

Your confusion appeared to be in thinking that a WU had a time allocated to it thus you were getting 36 hour WUs and there were 2 hour WUs. Each job in the queue is a WU and that WU will take as long as you allow it through your configuration (or less if it completes first) and will complete as many decoys as it has time to. Thus your question as stated really has no meaning - the total number of queued jobs is the total number of queued jobs regardless of the variable size which is under your control.

Your confusion appeared to be in thinking that a WU had a time allocated to it

No, I didn't mean that either.

Your confusion appeared to be in thinking that a WU had a time allocated to it

No, I didn't mean that either.

Then what of “The total number of queued jobs is the total number of WUs in the queue waiting to be sent” can we explain better?

For most projects one job is one work unit, but here we have variable work unit sizes creating multiple models apiece.

Like every other BOINC project, one job is still just one work unit, one Task.

The number of structures or decoys or whatever done within that one task isn't relevant. One Task is still just one Task.
As to what work is done & how it is reported or interpreted for a given Task is entirely up to each project, and each application that they may use.

And as for the amount of work done- that's what the Credits represent, the amount of work done over a given period of time. Once again, the number of structures or decoys or whatever done within that one task isn't relevant.


So, as we keep saying- One Task, is one job is one work unit, just like every other project.
Total Queued Jobs is just Rosetta's terminology for the number of Tasks ready to be sent out for processing, at Numberfields it's Tasks Ready to Send.

---

Grant
Darwin NT