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.

I think you can download osx version

Thanks, all. The High Sierra machine is my workshop station, crunches WUs 24/7 unless I'm in the shop (like now, sharpening an axe), so maybe I'll give that a shot. The other is my wife's desktop system. Not gunna mess too much with that one.

Best regards,
Tom C

And, while I was typing that, it downloaded 6 WUs. Murphy's Law!

Well Python Tasks in progress has finally cracked 20,000.
Which is only 4% of the compute resources that are (or were) available for Rosetta 4.20.

---

Grant
Darwin NT

The number of jobs is also down considerably.
Total queued jobs: 1,649,208

It looks like they weeded out a lot of them, either because they were producing errors or they were of low scientific priority.
So they may be getting a bit more realistic, though they still have a way to go to improve their app.

This is their best hope.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14930&postid=105000#105000
But they have to have someone on the job to do it.

---

This is their best hope.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14930&postid=105000#105000
But they have to have someone on the job to do it.

Who has the connection to the team?
Someone in touch with DEK?
He is the tech guru.

[quote]The number of jobs is also down considerably.
Total queued jobs: 1,649,208 [quote]

--------------

Queued job is not so important as unsent tasks.
That is what tells us what is coming really soon.