Rosetta has always been an experimental project imo.
Asking questions that have never been asked before, using tasks that have never been written before, with parameters whose limits may not be entirely obvious from the outset.
So if things go wrong, it should hardly be a surprise to anyone and no-one should get themselves worked up about it, especially when failures are a bigger problem for the project than they are for any one of us.
And that's the case here. How they chose to solve the problem is down to them, not us. Because they <can't> solve it and only users can in this instance.
Same as it ever was.

This is cutting edge science. But... they usually use Ralph first to test their ideas. This time they didn't. Such is life at the 'new' RAH.

It should, you're right, but it's never really worked. I've never bothered with Ralph.

Some people take the view there's no such thing as betatest software - you only need to look at the assurances you get from finished product, no guarantee it'll do what it's claimed to do.
It makes sense not to have any sense of entitlement as to the reliability of anything we get issued. That approach certainly saves time.

If we didn't have perpetual indignance on these message boards, the traffic would certainly be a lot less. From some accounts a lot more than others.

---

This is cutting edge science. But...they usually use Ralph first to test their ideas. This time they didn't. Such is life at the 'new' RAH.

I participate also to Ralph and it's "not a problem to have problems".
But here in Rosetta i would like a stable and tested work

---

If we didn't have perpetual indignance on these message boards, the traffic would certainly be a lot less. From some accounts a lot more than others.

I don't know if you're referring to me, but it's not important.
I have not a "perpetual indignance", often i write about science, about new languages or cpu/gpu features, etc.
A request, occasionally, of explanations i think it's not "indignance".

About "message board traffic" i'm agree with you: admins are vanished :-P

---

When i changed target cpu time from 1d12h to 2h and updated project in boinc manager workunits that were in progress at 7 hours didn't change their target cpu time to 2 hours and didn't finish.

When i changed target cpu time from 1d12h to 2h and updated project in boinc manager workunits that were in progress at 7 hours didn't change their target cpu time to 2 hours and didn't finish.

I recommend stopping them with LAIM off or exit BOINC ticking the box where it says "stop all applications".

---

Now WCG is down for 2 months, I moved back to Rosetta.

A lot of VirtualBox tasks get stuck for days and don't seem end. They expire on the server side, the work is lost and no points.
Don't want to babysit my computers...

Is there any fix for that? Other option is to disable Virtual Box work.

Which Vbox versions have you been using?
What other Vbox projects are you running?
Which computer are you referring to?
What is the load on your system?
How much memory is being used in terms of %? Do you get any error messages?
Do they go into "waiting to run" status a lot or are there any "need more memory" errors?
Do your machines run 24/7?
If not, before you close BOINC, do you suspend your work (and is the keep in memory option checked?) and then use the shut down client option before you exit?

All these things can be a factor.

This is cutting edge science. But...they usually use Ralph first to test their ideas. This time they didn't. Such is life at the 'new' RAH.

I participate also to Ralph and it's "not a problem to have problems".
But here in Rosetta i would like a stable and tested work

Rosetta is supposed to be stable and tested tasks with only minor errors that can be corrected quickly upon notification. That a team member just dumped the tasks on Rosetta and did not respond to any messages, shows the lack of commitment from the team towards their non neural network base.

Rosetta has always been an experimental project imo.
Asking questions that have never been asked before, using tasks that have never been written before, with parameters whose limits may not be entirely obvious from the outset.
So if things go wrong, it should hardly be a surprise to anyone and no-one should get themselves worked up about it, especially when failures are a bigger problem for the project than they are for any one of us.
And that's the case here. How they chose to solve the problem is down to them, not us. Because they <can't> solve it and only users can in this instance.
Same as it ever was.

This is cutting edge science. But... they usually use Ralph first to test their ideas. This time they didn't. Such is life at the 'new' RAH.

It should, you're right, but it's never really worked. I've never bothered with Ralph.

Some people take the view there's no such thing as betatest software - you only need to look at the assurances you get from finished product, no guarantee it'll do what it's claimed to do.
It makes sense not to have any sense of entitlement as to the reliability of anything we get issued. That approach certainly saves time.

If we didn't have perpetual indignance on these message boards, the traffic would certainly be a lot less. From some accounts a lot more than others.

We wouldn't be having all this discussion if the team would do its job and make sure things work and check the forum for problems with their task or assign a grad student who has the most work on RAH to monitor the forum for problems.

A resident expert from the team like DEK who knows the tech side of things, would be nice to have back to help with issues like Vbox stalling and all this other stuff we have been jabbering on about forever. But that is a thing of the past.

That Dr. B does not post here in the forum should tell you a lot. Last post from him was 2017.
Admin is absent and so is Mod Sense.
That we have two spammers in news or another thread and no one does anything about it.....

Welcome to the wild west of RAH forums.

Seems the disk space errors are caused by leave the use x GB free box unchecked and blank.

GitHub guys made a discovery that this has been an issue in the past.

Something in the program code if I understood it correctly.

So I set the value to 300 out of 365. That should solve my sporadic problem in theory.

Seems the disk space errors are caused by leave the use x GB free box unchecked and blank.

GitHub guys made a discovery that this has been an issue in the past.

Something in the program code if I understood it correctly.

So I set the value to 300 out of 365. That should solve my sporadic problem in theory.

I also set the "Use at most ...% of the total disk space" to 100%.
It has been commented on in this (and other) forums for some time, but gets lost in the other comments.

---

To arrive at the settings I use , In my experimentations I found things like if I set :-

Use no more than - 500 GB 
Leave at least - 0 GB free
Use no more than - 100 % of total

The "Leave at least" and "Use no more than"
Boxes untick themselves when saving leaving the values boxes blank , od behaviour ,
and the total disk space changes from 137.57GB to 137.58 GB , funny old world .

It will let me go as far as "Leave at least - 0.01 GB free" but rejects 0.001 and then unticks and blanks the box.
The % box can go blank at times for some reason
In the long run It works ,
other fun stuff :-)

I suspect the error is in function max_allowable_disk here:
https://github.com/BOINC/boinc/blob/master/sched/sched_send.cpp#L348

While disk_max_used_gb=0 is thought to be interpreted "unlimited" L360 sets a default limit of 100GB.
If hit this results in x1 (L377-L381) being the limiting "x".

Same can happen to x2 if the client is installed on small disks since L363 sets prefs.disk_max_used_pct to a default of 50.

Workaround for older clients:
Don't leave disk_max_used_gb and disk_max_used_pct at "0".
Instead use higher limits.

--computezrmle (who is also seen around this project from time to time)

I clearly stated it as a guess at github, hence you shouldn't cite it until more experienced developers have checked unwanted side effects and confirm the guess is right.
Even then, it does not solve anything in any BOINC client currently in use.

It seems to have solved my issue using a current version of BOINC.

And while not a absolute guarantee, it does take away all the messing around with settings and guess work we are doing now and if it works as a patch, great.

So, Rosetta running using BOINC 7.16.19, MacOS 10.13.6 and MacOS 12.2.1.

I have no clue what this message means, nor how to deal with it. I haven't run Rosetta in a number of years, been on WCG for quite some time now.

Sat Feb 26 13:25:42 2022 | Rosetta@home | Sending scheduler request: To fetch work.
Sat Feb 26 13:25:42 2022 | Rosetta@home | Requesting new tasks for CPU
Sat Feb 26 13:25:44 2022 | Rosetta@home | Scheduler request completed: got 0 new tasks
Sat Feb 26 13:25:44 2022 | Rosetta@home | No tasks sent
Sat Feb 26 13:25:44 2022 | Rosetta@home | Message from server: VirtualBox is not installed
Sat Feb 26 13:25:44 2022 | Rosetta@home | Project requested delay of 31 seconds

Can someone help a guy out with an explanation? Many thanks...

Tom C

---

Install virtualbox from here
https://www.virtualbox.org/wiki/Downloads
https://download.virtualbox.org/virtualbox/6.1.32/VirtualBox-6.1.32-149290-OSX.dmg

Install virtualbox from here
https://www.virtualbox.org/wiki/Downloads
https://download.virtualbox.org/virtualbox/6.1.32/VirtualBox-6.1.32-149290-OSX.dmg

Um. OK. And then what? Is the suggestion that I run the ?linux? ?wintel? version of BOINC in a virtual machine? No thanks.

The High Sierra machine processed a bunch of units but cannot get any more, the other is working thru the units it has, but cannot get any new ones.

Yes, I'm confused.

https://boinc.berkeley.edu/wiki/VirtualBox
It seems all not virtualized workunits are already distributed to computers.
https://boinc.bakerlab.org/rosetta/server_status.php
I think status page is updated every hour.
https://boinc.bakerlab.org/rosetta/server_status.php

https://boinc.berkeley.edu/wiki/VirtualBox
It seems all not virtualized workunits are already distributed to computers.
https://boinc.bakerlab.org/rosetta/server_status.php
I think status page is updated every hour.
https://boinc.bakerlab.org/rosetta/server_status.php

I think see.

So, my options are:
1) install virtualbox and, presumably a linux OS
2) wait for "unvirtualized" work units to show up
3) find another project

Is there a #4?

Thanks.

Um. OK. And then what? Is the suggestion that I run the ?linux? ?wintel? version of BOINC in a virtual machine? No thanks.

The virtual tasks include an operating system that will run on the virtual machine, usually a stripped down version of Linux.

You don't need to know which one unless you are creating the task.

The High Sierra machine processed a bunch of units but cannot get any more, the other is working thru the units it has, but cannot get any new ones.

Yes, I'm confused.

Rosetta@Home is creating tasks much slower than people are trying to download them, so expect frequent problems in trying to get more tasks.