Minor problem, Acronis true image 2020 active protection malware detection on my windows 10 PC flagged Rosetta beta 6.06 (rosetta_beta_6.06_windows_x86_64.exe) as possible malware.

AV/Malware programmes have been giving false positives for BOINC programmes for years.

---

Grant
Darwin NT

Minor problem, Acronis true image 2020 active protection malware detection on my windows 10 PC flagged Rosetta beta 6.06 (rosetta_beta_6.06_windows_x86_64.exe) as possible malware.

AV/Malware programmes have been giving false positives for BOINC programmes for years.

Yes.
Guess who runs both Norton 360 and Acronis TrueImage...

---

then paste the following two lines:

128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

Thanks a lot for advise!

---

i crunch for Ukraine. Join our team forums about Rosetta@home

I was just about to post about the feeder not running issue which was weird since 3 of my 4 rigs connected to the project without any issues and got a few WUs too.
Editing the hosts file was an instant fix, thanks a lot!

I note that this host: https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=6282139

Is running it's tasks at near a day per task. And getting some excellent production.

And seems to be getting better total production than I am on a single 128 thread Epyc CPU. (The system appears to be a 2 cpu, 128 thread system). I am wondering if changing my profile to run near 24 hour tasks will increase my total production?

Thank you.

---

Help, my tagline is missing..... Help, my tagline is......... Help, m........ Hel.....

I am wondering if changing my profile to run near 24 hour tasks will increase my total production?

Try it and see.
IMHO- it won't.


There is one main difference between your system and their system- performance per core/thread.

                                   Theirs               Yours
Measured floating point speed  5711.18 million        5271 million
Measured integer speed        89112.65 million    14824.93 million

Theirs does more work per hour, so it gets more Credit per hour.


Your CPU has a higher boost clock, however that boost clock is the absolute maximum possible for any single core. All cores running at full load- the max possible boost for each will be lower. A CPU with less cores, but similar cooling area, will likely sustain higher over-all boost clocks for all cores.
So more work done per hour per core/thread.

---

Grant
Darwin NT

I note that this host: https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=6282139

Is running it's tasks at near a day per task. And getting some excellent production.

And seems to be getting better total production than I am on a single 128 thread Epyc CPU. (The system appears to be a 2 cpu, 128 thread system). I am wondering if changing my profile to run near 24 hour tasks will increase my total production?

Thank you.

I think the answer is generally no and also specifically in this case no.
From its details, the host you quote has this performance

Measured floating point speed	5711.18 million ops/sec
Measured integer speed	89112.65 million ops/sec

While yours shows

Measured floating point speed	5271 million ops/sec
Measured integer speed	14824.93 million ops/sec

And I think that, more than anything, reflects the other one's better production.

As a generalisation, your production for time spent is the same however long the task runs, only improving by saving the tiniest amount of startup/shutdown overhead.
The cost of which might be a bigger loss if any task should crash mid-run, where you might not be awarded any credit.

As a side issue, ploughing through your completed tasks, your cache size is just that touch too large so that some are cancelled by the server for not starting before deadline
Your combined "store at least x days and up to an additional y days of work" looks like it might be too close to 3 whereas, allowing for an 8hr task runtime plus the potential of tasks running longer, I'd keep that to a maximum of ~2.3 to avoid server cancellations by Rosetta and ensuring you're always credited for work done. You might stretch that to 2.5, but sometimes "things happen" particularly if you run multiple projects on that host.
Does that make sense compared to what your settings actually read?

---

I am wondering if changing my profile to run near 24 hour tasks will increase my total production?

Try it and see.
IMHO- it won't.

Typical...

Apart from repeating each other, setting Rosetta runtime to anything other than 8hrs really messes up Boinc's scheduling at the time of downloading.
Unless there's a lot in hand between total cache size and deadlines, I wouldn't shift from Rosetta's 8hr default runtime, especially if other projects run on that host.
It has the potential to get very ugly imo

---

I think the answer is generally no and also specifically in this case no.
From its details, the host you quote has this performance

Measured floating point speed	5711.18 million ops/sec
Measured integer speed	89112.65 million ops/sec

While yours shows

Measured floating point speed	5271 million ops/sec
Measured integer speed	14824.93 million ops/sec

And I think that, more than anything, reflects the other one's better production.

That's not how that works.
Those numbers are the result of running the benchmarks.

It shows that one system is inherently faster than the other from a compute perspective. All things being equal- one will outperform the other, that being the one with the higher benchmark numbers.
So for those two systems, if both were to run the same application and process the same Task for the same period of time, the one with the higher benchmarks would get more Credit because it is doing more work in that period of time.


The actual* processing performance is indicated by the Device peak FLOPS shown in the Task.

* although even that is not an accurate indicator, such as for GPUs- running multiple Tasks can produce more work per hour, even though the Device FLOPS number then is much lower than when processing a single Task, which produces less work per hour.
But if you have two systems running the same number of Tasks per core/thread then the one with the higher Device peak FLOPS will get more Credit per hour because it's doing more work per hour.




As for the vagrancies of Credit here- the only way to see if you will get more Credit per hour running Tasks for longer than if you run them for a shorter period is to try it and see.
I didn't find any difference when i tried it, Sid reckons there is.
*shrug*

Keeping in mind different batches of Tasks can result in differing amounts of Credit (hell, even the same batch that runs for the same time on the same system will get differing amounts of Credit).
If you compare the Credit earned per hour between the two systems, yes the other one running the Task for longer is getting more Credit per hour- but that difference per hour is roughly on par with the difference in benchmarks.

---

Grant
Darwin NT

I have a task that is now overdue that won't upload/report to the server keeps getting the message "Server error: feeder not running".
I already have the hosts file workaround "installed" and according to the unreliable server status page all is green.
Anyone else having problems upload/report tasks?

Sat 03 May 2025 11:26:46 AM CDT | Rosetta@home | update requested by user
Sat 03 May 2025 11:26:48 AM CDT |  | [http_xfer] [ID#0] HTTP: wrote 347 bytes
Sat 03 May 2025 11:26:50 AM CDT | Rosetta@home | Fetching scheduler list
Sat 03 May 2025 11:26:52 AM CDT |  | [http_xfer] [ID#1] HTTP: wrote 16384 bytes
Sat 03 May 2025 11:26:52 AM CDT |  | [http_xfer] [ID#1] HTTP: wrote 8193 bytes
Sat 03 May 2025 11:26:52 AM CDT | Rosetta@home | Master file download succeeded
Sat 03 May 2025 11:26:58 AM CDT | Rosetta@home | Sending scheduler request: Requested by user.
Sat 03 May 2025 11:26:58 AM CDT | Rosetta@home | Reporting 1 completed tasks
Sat 03 May 2025 11:26:58 AM CDT | Rosetta@home | Not requesting tasks: don't need ()
Sat 03 May 2025 11:26:58 AM CDT |  | [http_xfer] [ID#1] HTTP: wrote 171 bytes
Sat 03 May 2025 11:26:59 AM CDT | Rosetta@home | Scheduler request completed
Sat 03 May 2025 11:26:59 AM CDT | Rosetta@home | Server error: feeder not running
Sat 03 May 2025 11:26:59 AM CDT | Rosetta@home | Project requested delay of 3600 seconds

The last, edited, entry below is 4 minutes ago:

Sat 03 May 2025 10:14:47 | Started download of 12mrredo_12_hallucinated_102_160.zip
Sat 03 May 2025 10:14:47 | Started download of 12mrredo_12_hallucinated_102_160.flags
Sat 03 May 2025 10:14:49 | Finished download of 12mrredo_12_hallucinated_102_160.zip (3582 bytes)
Sat 03 May 2025 10:14:49 | Finished download of 12mrredo_12_hallucinated_102_160.flags (1020 bytes)
Sat 03 May 2025 10:15:15 | Sending scheduler request: To fetch work.
Sat 03 May 2025 10:15:15 | Requesting new tasks for CPU
Sat 03 May 2025 10:15:18 | Scheduler request completed: got 0 new tasks
Sat 03 May 2025 10:15:18 | No tasks sent
Sat 03 May 2025 10:18:29 | Computation for task RosettaVS_SAVE_ALL_OUT_NOJRAN_GATA2_boinc_fulldb_IGNORE_THE_REST_yqauji_1_7213_3022008_1_0 finished
Sat 03 May 2025 10:18:29 | Starting task 11mrredo_11_hallucinated_171_70_SAVE_ALL_OUT_3013890_343_0
Sat 03 May 2025 10:18:32 | Started upload of RosettaVS_SAVE_ALL_OUT_NOJRAN_GATA2_boinc_fulldb_IGNORE_THE_REST_yqauji_1_7213_3022008_1_0_r1270265219_0
Sat 03 May 2025 10:18:38 | Finished upload of RosettaVS_SAVE_ALL_OUT_NOJRAN_GATA2_boinc_fulldb_IGNORE_THE_REST_yqauji_1_7213_3022008_1_0_r1270265219_0 (152549 bytes)

---

I have a task that is now overdue that won't upload/report to the server keeps getting the message "Server error: feeder not running".
I already have the hosts file workaround "installed" and according to the unreliable server status page all is green.

Double check that the Hosts entry is still there.
Apparently some AV/Anti-malware programmes get upset if it is changed manually & revert it.

---

Grant
Darwin NT

[quotes]
As a generalization, your production for time spent is the same however long the task runs, only improving by saving the tiniest amount of startup/shutdown overhead.
The cost of which might be a bigger loss if any task should crash mid-run, where you might not be awarded any credit.

As a side issue, ploughing through your completed tasks, your cache size is just that touch too large so that some are cancelled by the server for not starting before deadline
Your combined "store at least x days and up to an additional y days of work" looks like it might be too close to 3 whereas, allowing for an 8hr task runtime plus the potential of tasks running longer, I'd keep that to a maximum of ~2.3 to avoid server cancellations by Rosetta and ensuring you're always credited for work done. You might stretch that to 2.5, but sometimes "things happen" particularly if you run multiple projects on that host.
Does that make sense compared to what your settings actually read?[/quote]

I checked and I was running the Cache at 1.0 day of work and store an additional 0.1 days of work.

I have dropped that to 0.5 days of work.

===edit===
I am running a private label version of the boincmgr. And I got to looking in the Pandora config file and it is set to allow up to 2000 CPU tasks. I have dropped that to 1,000 tasks.

---

Help, my tagline is missing..... Help, my tagline is......... Help, m........ Hel.....

There is one main difference between your system and their system- performance per core/thread.

                                   Theirs               Yours
Measured floating point speed  5711.18 million        5271 million
Measured integer speed        89112.65 million    14824.93 million

Theirs does more work per hour, so it gets more Credit per hour.


Your CPU has a higher boost clock, however that boost clock is the absolute maximum possible for any single core. All cores running at full load- the max possible boost for each will be lower. A CPU with less cores, but similar cooling area, will likely sustain higher over-all boost clocks for all cores.
So more work done per hour per core/thread.

Thank you. I was wondering how a 2 cpu system with the same number of threads (and generation of gpu) was getting higher production.

And I overlooked the well-known fewer threads per cpu allows them to run faster experience I have had.... mumble.

---

Help, my tagline is missing..... Help, my tagline is......... Help, m........ Hel.....

I am wondering if changing my profile to run near 24 hour tasks will increase my total production?

Try it and see.
IMHO- it won't.
.

I have created a profile with the longer runtime. I will let it run for a while. And then probably revert to the 8 hour profile.

Sigh. Now if I could overclock a server cpu..... ;)

---

Help, my tagline is missing..... Help, my tagline is......... Help, m........ Hel.....

I have a task that is now overdue that won't upload/report to the server keeps getting the message "Server error: feeder not running".
I already have the hosts file workaround "installed" and according to the unreliable server status page all is green.

Double check that the Hosts entry is still there.
Apparently some AV/Anti-malware programmes get upset if it is changed manually & revert it.

I did confirm it's still there before posting and I doubt it will be removed by a nonexistent AV program on Linux/Ubuntu.

That's not how that works.

Oh...
I thought, because I pointed at the same lines as you to come to the same conclusion as you, we were saying much the same thing.
Apparently not

As for the vagrancies of Credit here- the only way to see if you will get more Credit per hour running Tasks for longer than if you run them for a shorter period is to try it and see.
I didn't find any difference when I tried it, Sid reckons there is.

Err... I had thought I reckoned I wouldn't find a difference too.
I really did think we were agreeing - you in a more detailed way, me in a more general way.

Maybe I lost track along the way before, but I'm not disagreeing with you now.
Unless you tell me I am.. lol

---

Does that make sense compared to what your settings actually read?

I checked and I was running the Cache at 1.0 day of work and store an additional 0.1 days of work.

I have dropped that to 0.5 days of work.

===edit===
I am running a private label version of the boincmgr. And I got to looking in the Pandora config file and it is set to allow up to 2000 CPU tasks. I have dropped that to 1,000 tasks.

I don't know anything about your 'private label' version of boincmgr, but it seems like it's taking complete control over the number of tasks coming down as your cache + additional days figure was entirely reasonable (and you could revert that back if that's your preference).

However, when you later write...

I have created a profile with the longer runtime. I will let it run for a while. And then probably revert to the 8 hour profile.

Your cache seems to hold 870 tasks (including running tasks).
The way Rosetta works is it initially tells Boinc tasks will take 8hrs, even if you've adjusted tasks to have a 24hr runtime,

870 tasks at 8hrs on a 128 thread server will take ~2.25days to complete - within the 3-day deadline.
But if they end up running 24hrs, they'll take ~6.75days to complete - ALL missing deadline.
Then your earlier unstarted tasks will get cancelled for not starting before deadline, while simultaneously grabbing more tasks because Rosetta (not Boinc) is misleading Boinc as to how big your cache is.

Any cache of tasks larger than 3days*128threads=384 running 24hrs each will miss deadline
The longest runtime your current cache size can successfully complete inside deadline is 10hrs - not notably different to the default 8hrs

The point being, with a fixed 3day deadline, if you treble runtime you have to reduce your cache-size an equivalent amount to continue to meet that hard deadline

---

I checked and I was running the Cache at 1.0 day of work and store an additional 0.1 days of work.

Additional days is best set to 0.01.
ie if you want 2 days of work then set it to 2.0 days of work and store an additional 0.01 days. 0.5 days of work, then set it to 0.5 days of work and store an additional 0.01 days. 1.35 days of work? Then set it to 1.35 days of work and store an additional 0.01 days.

The additional days setting doesn't work the way people think it will.
People think a setting of 1.0 day of work and store an additional 10.0 days will give them a minimum of 11 days of work. It won't.
Initially the system will load up 11 days of work, however it won't get new work until it drops below the 1.0 days setting. Then it will fill up another 11 days of work, to drop down to below 1 day before re-filling again...



As as Sid posted- if you increase your Run time, then you need to decrease your cache as the Initial Estimated processing time is fixed at 8 hours, regardless of how long a Task actually runs for.
With multiple projects 0.01 days and 0.01 additional days is best, or 0.1 days and 0.01 additional days if you really feel the need for some cache.

---

Grant
Darwin NT

However, when you later write...

I have created a profile with the longer runtime. I will let it run for a while. And then probably revert to the 8 hour profile.

Your cache seems to hold 870 tasks (including running tasks).
The way Rosetta works is it initially tells Boinc tasks will take 8hrs, even if you've adjusted tasks to have a 24hr runtime,

870 tasks at 8hrs on a 128 thread server will take ~2.25days to complete - within the 3-day deadline.
But if they end up running 24hrs, they'll take ~6.75days to complete - ALL missing deadline.
Then your earlier unstarted tasks will get cancelled for not starting before deadline, while simultaneously grabbing more tasks because Rosetta (not Boinc) is misleading Boinc as to how big your cache is.

Any cache of tasks larger than 3days*128threads=384 running 24hrs each will miss deadline
The longest runtime your current cache size can successfully complete inside deadline is 10hrs - not notably different to the default 8hrs

The point being, with a fixed 3day deadline, if you treble runtime you have to reduce your cache-size an equivalent amount to continue to meet that hard deadline

Yeah, this is actually happening as predicted above.
You currently have 1100 errored tasks, largely comprising "Not started by deadline - canceled" plus "Timed out - no response" for those tasks that have started.
And for those you have returned they have been awarded credited, which is fortunate because all your 24hrs tasks missed deadline by up to a day.
And you seem to have tried reducing your runtime to 22hrs or 20hrs and it's not producing any better outcomes.
The other thing we can say is that while each task is getting credited more, you're not noticeably getting any better credit/hr much as predicted again, so it's a futile exercise.

It's perfectly legitimate to want to run longer runtimes, if you're happy with the risk of tasks crashing in that extra time and not being rewarded with any credits, but that requires a maximum number of tasks in the 300-350 range when using 24hr runtimes - and, importantly, <waiting> for your cache to actually reduce to 300-350 <before> increasing runtime from 8 to 24hrs in order to avoid these timeouts and cancellations.

By all means confirm that for yourself - your tasklist looks like a bit of a warzone atm with all its red warning messages

If you want to keep your settings as they currently are I think you may squeeze through with 12hr runtimes as a certain number of tasks are crashing out of their own accord in the current batch (project-related, not user-related)
I'm using 12hr runtimes quite successfully atm (albeit with a smaller cache). My personal view is that it will be a workable compromise setting for you of longer runtime vs completion by deadline. YMMV

---