Add the following two lines to the end of your hosts file.

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

The file might be *hidden, system and/ or read only* and is located as noted below (Change all the / to ).

C:/Windows/System32/Drivers/etc/hosts

You might need to disable anti-virus and/or anti-malware software (Norton's, Microsoft's built-in Anti-virus; etc; temporarily to edit it.

*To change the file attributes, open a "DOS prompt" command line "C:>" and type (without the quotes)
"Attrib -h -s -r C:/Windows/System32/Drivers/etc/hosts"

Now to edit the file.. At the same command prompt type (without the quotes)
"Notepad C:/Windows/System32/Drivers/etc/hosts"

Or Use a text editor such as NOTEPAD.exe to edit the file, save it with "all extensions *.*" as plain text.

I found nothing labelled DOS prompt. I found what appears to be the hosts file and edited it it to add the lines. I found nothing to make the changes take effect, so I rebooted the computer. Still no signs of the changes taking effect.

I found nothing labelled DOS prompt. I found what appears to be the hosts file and edited it it to add the lines. I found nothing to make the changes take effect, so I rebooted the computer. Still no signs of the changes taking effect.

Re-open the file hosts in "C:/Windows/System32/Drivers/etc/" and make sure that
128.95.160.156 boinc-files.bakerlab.org
128.95.160.156 bwsrv1.bakerlab.org

are in there.

I personally find it easier to copy the hosts file to another location, edit and save it, then rename the exiting hosts file hosts.old, then copy the just edited file back in to the "C:/Windows/System32/Drivers/etc/" folder.
Much easier than mucking around with permissions IMHO.

---

Grant
Darwin NT

Hi, I'm facing the problem, that I'm not able to select the specific application I want to run (in my profile settings).

I'm using BOINC since 2008 and back in the middle of the ages it was possible to select this in your profile settings (along with the option to receive WUs for other applications if there are now WU's for your currently selected application), specificially I want to avoid receiving beta WU's here at "normal" Rosetta@home. I dont have and never had an account for the R@h Beta project but do receive beta WU's here. I know, that according to the server status there are no "normal" WU's right now but pls let me uncheck receiving beta WUs, they are useless for my system. When I abort them on my system, its decreasing the trust factor of this system and keeps me busy for no good reason.

Thanks guys. :)

Got my last new task at 09:22 UTC, only some resends after that moment.

I still have over 600 tasks cached (630-650 was the normal interval while there was a constant supply) but I don't expect resends to be able to hold the line for long. Was a nice run though, let's hope there will be more in the new year. Until then I'm moving over to SiDock and WCG as secondary.

Yes, just a little longer than expected.
The number of tasks you have seems like a lot, so I took a look to see you have several PCs running, but the majority are running tasks for barely more than 2hrs, for which you're getting very little credit, while using up tasks faster than expected.
I don't mean to drag you into the discussion we're having elsewhere, but it will make an enormous difference to how long batches of tasks last if you change your Rosetta Target CPU runtime explicitly to 8 hours here, matching the time Boinc schedules unstarted tasks for, and limit your cache to 2-2.5 days at most to ensure they complete within their deadlines.
The limited number of tasks we get at a time will last a lot longer and can be shared out among more users, while you'll see a massive credit boost per task and a smaller credit boost overall.

Right now I have set all PCs to run tasks for 4 hours because some PCs behave unpredictably and may actually run tasks for longer (mainly the i7-1165G7 and, somewhat surprisingly, the Ultra 5 125H). The Ryzen 5285Us should be fine running regular 8 hour tasks (with a somewhat reduced cache for safety), but the first two would probably need an even smaller cache, under 2 days. I will try messing around with the setting but until the next large wave of work I won't really be able to stress test the setup.

I did read parts of the discussion you mentioned but will admit that I also didn't put in the effort to properly read and assimilate everything.

Either way, thanks for the tip! I'm making changes right now.

Fair enough if you've got reliability concerns. You have to do whatever you need to to remain successful.
By all means run a smaller cache than 2 days if you need to as well - I got the impression one or two of your machines run a pretty large cache already and 8hr runtimes may push you past Rosetta's 3-day deadline

---

I want to avoid receiving beta WU's here at "normal" Rosetta@home.

Along with many other issues with the project- that is another one.
The Beta Tasks aren't actually Beta Tasks- they are production Tasks, with Beta in their name.

The only difference between them and the Rosetta 4.20 Tasks (from a processing point of view) is the default Run time, and they generally require much less RAM than the Rosetta 4.20 Tasks.
They are producing Valid science, they are not being run for the sake of testing.


The site for doing actual Beta testing, has been deader than a dodo for almost 18 months.

---

Grant
Darwin NT

Fair enough if you've got reliability concerns. You have to do whatever you need to to remain successful.
By all means run a smaller cache than 2 days if you need to as well - I got the impression one or two of your machines run a pretty large cache already and 8hr runtimes may push you past Rosetta's 3-day deadline

Here's the current, possibly final setup:
- I kept the 4-hour runtime on the Intel Ultra and the old i7-1165G7 which both tend to run longer than the set time.
- After testing 12-hour tasks which resulted in similar credits/hour as the regular 8-hour tasks, I'll keep the 2 workhorse 5825Us and two old Intels with 8-hour tasks. Cache is set to 2+0,5 days on all machines.

---

Thanks Grant for clarifying this.

In this case I will reconsider running Rosetta. Seems many of the BOINC projects are dead or having issues nowadays (*cough* WCG *cough*).

Well it was a good run. Looks, to me, like it was about 3 weeks of tasks. I've got maybe a days worth in the queue(s). Now new taskings have dropped to pretty much nil and I've turned WCG back on.

---

- I kept the 4-hour runtime on the Intel Ultra and the old i7-1165G7 which both tend to run longer than the set time.

Which indicates their CPU's are busy doing work other than BOINC.
If this shouldn't be the case, you can use Task Manager (or better yet Process Explorer) to see what else is making use of the CPU.
Or you can make use of the local settings (or separate web based preferences) to limit the number of cores/threads BOINC can use so that BOINC processing isn't impacted by the other work on the system that's taking up CPU time.

Cache is set to 2+0,5 days on all machines.

xx days + 0.01 additional days is best.
The larger the additional days setting, the lower the cache falls from it's full capacity before it refills...

---

Grant
Darwin NT

Which indicates their CPU's are busy doing work other than BOINC.
If this shouldn't be the case, you can use Task Manager (or better yet Process Explorer) to see what else is making use of the CPU.
Or you can make use of the local settings (or separate web based preferences) to limit the number of cores/threads BOINC can use so that BOINC processing isn't impacted by the other work on the system that's taking up CPU time.

There are periods when those laptops are used, but they also idle a lot and are running 24/7. The Ultra 5 has a mix of performance and efficiency cores and I think it swaps tasks between them while running. I've seen the same pattern with all projects on that laptop. When running very standardized tasks like WCG I can sometimes see the 8+10 thread setup based on the speed at which tasks are running.

The other laptop is old and worn out, it simply runs all tasks longer than expected, in every project.

xx days + 0.01 additional days is best.
The larger the additional days setting, the lower the cache falls from it's full capacity before it refills...

Oh, I wasn't aware, thanks for pointing it out!

---

The Ultra 5 has a mix of performance and efficiency cores and I think it swaps tasks between them while running. I've seen the same pattern with all projects on that laptop. When running very standardized tasks like WCG I can sometimes see the 8+10 thread setup based on the speed at which tasks are running.

The other laptop is old and worn out, it simply runs all tasks longer than expected, in every project.

It's not a core swapping or old and tired issue- what is is that BOINC Tasks are lower priority than many others.
So when something else is running on the system, the BOINC tasks keep running, but they get less CPU time, hence the difference between CPU time (actual processing) and Run time (how long it actually takes to do that processing- think clock on the wall).
Those systems are just as capable of doing 8 hours of work in only a little over 8 hours of time, just like your other systems.

eg
this Task
12 hours to actually do 7 hrs 12min of processing would be because the CPU is busy doing non-BOINC work.
On 2 of my systems i ended up using 3rd party AV software because Microsoft Defender on those Win10 systems ended up using a core/thread for extended periods of time for no obvious reason.
On a previous Win7 system i ended up disabling Windows Update because the Windows updater service would start up and never shut down, using 50% of my CPU.

And the way i found these issues occurring- the big difference between CPU time & Run time for Tasks on those systems, and Process Explorer to see what was going on.
The other easier option is just to limit the number of cores/threads available to BOINC.


If the other software needs 1, take 1 from BOINC. If it needs 5, take 5 from BOINC. End result- 7hrs 15min to do 7hrs 12min of work instead of 12hrs.

---

Grant
Darwin NT