I'm soread out over a bunch of projects. WCG, SiDock, Quchem (though it never runs stable for me) for health projects. I do a few science and math projects as well. And Folding at home outside of BOINC.

If you look at Python tasks, they are running Aimnet stuff which isn't there work. Atoms in Molecules. It's quite complex.

But yes your right, Dr. B dropped off years ago, pre covid even. Moderators disappeared. Used to have grad students tell us what's going on, but that's gone. The task creators used to monitor here for bugs, but not any more.

But despite this, people join and stay.

@ BoredEEdude
Try this
...
Use no more than - 500 GB . . don't worry about setting this BIG. even if you set this bigger than the disk , it works.
Leave at least ## GB free . . [untick this box not needed]
Use no more than ## % of total . . [untick this box not needed]
try it , see what happens , pythons are a pain.

I changed to using just the "Leave at least _____ GB free" setting about 30 minutes before reading your post about using just the "Use no more than _____ % of total" setting.

Well, by the next day the BOINC client was only running 3-4 python tasks with about 12 more waiting to run, even though the CPU was almost down to an idle and there was plenty of free memory. Those 15 tasks were also the only tasks in the queue, and requesting and update didn't get more tasks. The same server side error about low disk space had also showed up again. The day before the new settings arriving had gotten up to about 218 GB in use, then it fell back down overnight to around 70 GB as tasks were completed.

So I unchecked the "Leave at least 50 GB free" setting,
and used .clair.'s suggestion of just "Use no more than 500 GB" instead.

Since the client had not started up and existing tasks into available free memory and CPUs, I then restarted BOINC manager. After restart, about 20 new tasks were downloaded immediately, and in short order 10 python tasks were up and running at the same time.

Now to wait and see if this new setting is more stable for me over time.

It's pure pragmatism. If it wasn't for the bad news, there wouldn't be any news at all.
Sorry and thanks for your time and effort.
Bygones.

Are you inviting me to abandon the project?
I'm Italian, so my English is not so good...

Even in English, it's an obscure phrase based on a 25yo TV programme.
Basically, it means that if you took offence at a comment that was simply a statement of fact, and need an apology and thanks, here it is.
But because it was never the point, I'm not going to get bogged down by worrying about it.

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.
And the longer someone has been here, the more apparent it should be after all this time.
I guess, for some, the penny never drops. So here we are.

---

@ BoredEEdude
Try this
...
Use no more than - 500 GB . . don't worry about setting this BIG. even if you set this bigger than the disk , it works.
Leave at least ## GB free . . [untick this box not needed]
Use no more than ## % of total . . [untick this box not needed]
try it , see what happens , pythons are a pain.

I changed to using just the "Leave at least _____ GB free" setting about 30 minutes before reading your post about using just the "Use no more than _____ % of total" setting.

As I write this, the BOINC server notice about needing more space has gone away, so I'm assuming my change is working for now. If I get a new server error about lacking space, I will give your approach a try.

I also just saw my first 3 valid python tasks accepted by the server a few minutes ago, so my main problem of VirtualBox tasks not working seems to be fixed. For now I just want to see if everything keeps running smoothly for the next few days. If I keep tinkering with the settings it might just confuse the server further in the short term.

Your Windows says you have 667Gb free.
Your Boinc says
[x] Use no more than 100 GB
[x] Leave at least 1 GB free
[x] Used no more than 50% of total

Those settings don't make much sense together, so deselect 3 and increase 1 to 300Gb (increase 2 for safety if you like)
On your next update, I expect you to get a lot more tasks immediately.

---

It's not a server error, it's BOINC manager telling you that the project on your computer thinks it needs more disk space.

My solution was to uncheck everything but the GB free box and set that at 2 GB. I still got a one time error about disk space which was nonsense when you have over 360 GB free on a dedicated drive.

Since that one time error I have never had that problem. I was running 15 pythons at the time.

It's not a server error, it's BOINC manager telling you that the project on your computer thinks it needs more disk space.

My solution was to uncheck everything but the GB free box and set that at 2 GB. I still got a one time error about disk space which was nonsense when you have over 360 GB free on a dedicated drive.

Since that one time error I have never had that problem. I was running 15 pythons at the time.

It's pure pragmatism. If it wasn't for the bad news, there wouldn't be any news at all.
Sorry and thanks for your time and effort.
Bygones.

Are you inviting me to abandon the project?
I'm Italian, so my English is not so good...

Even in English, it's an obscure phrase based on a 25yo TV programme.
Basically, it means that if you took offence at a comment that was simply a statement of fact, and need an apology and thanks, here it is.
But because it was never the point, I'm not going to get bogged down by worrying about it.

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.
And the longer someone has been here, the more apparent it should be after all this time.
I guess, for some, the penny never drops. So here we are.

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.

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.

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.

They are easier to spot if you install BoincTasks. It shows the CPU useage, and when you see it in red that means the CPU is not doing much.
You can delete them in the first five minutes if you catch them.

Otherwise, the project has to fix it, if there is anyone at Rosetta at all.

(It would be nice if some software expert could automate the process.)

---

https://efmer.com/boinctasks/download-boinctasks/

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.

They are easier to spot if you install BoincTasks. It shows the CPU useage, and when you see it in red that means the CPU is not doing much.
You can delete them in the first five minutes if you catch them.

Otherwise, the project has to fix it, if there is anyone at Rosetta at all.

(It would be nice if some software expert could automate the process.)

Thanks!

I'm used to look at my rigs once a week, sometimes 2 times in a month... Before the VB work, I ran Rosetta for a year without many issues.

I guess they'll have to fix it while I focus on non-VB work or another project....

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.

They are easier to spot if you install BoincTasks. It shows the CPU useage, and when you see it in red that means the CPU is not doing much.
You can delete them in the first five minutes if you catch them.

Otherwise, the project has to fix it, if there is anyone at Rosetta at all.

(It would be nice if some software expert could automate the process.)

Thanks!

I'm used to look at my rigs once a week, sometimes 2 times in a month... Before the VB work, I ran Rosetta for a year without many issues.

I guess they'll have to fix it while I focus on non-VB work or another project....

Check your Vbox version and extensions version. You may need to update to get stable.

I forgot about WCG going down. I guess I need to disable that project for now.
You can try another Vbox project, I can't get it to be stable on my rig for some reason, others have lots of success. Look up QuChemPedia.

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.

They are easier to spot if you install BoincTasks. It shows the CPU useage, and when you see it in red that means the CPU is not doing much.
You can delete them in the first five minutes if you catch them.

Otherwise, the project has to fix it, if there is anyone at Rosetta at all.

(It would be nice if some software expert could automate the process.)

Thanks!

I'm used to look at my rigs once a week, sometimes 2 times in a month... Before the VB work, I ran Rosetta for a year without many issues.

I guess they'll have to fix it while I focus on non-VB work or another project....

Check your Vbox version and extensions version. You may need to update to get stable.

I forgot about WCG going down. I guess I need to disable that project for now.
You can try another Vbox project, I can't get it to be stable on my rig for some reason, others have lots of success. Look up QuChemPedia.

I turned of VB work for now, it's not worth it. Just had to abort another 22 units that got stuck, waste of CPU-cycles and no points.
Will start looking for another project in the coming days or just shut them down the machines until WCG is back.

Another batch of work released, and only some of these error out straight away. Not great, but still better than all of them doing it.

---

Grant
Darwin NT

5 4.20 tasks running, two failed immediately, one rosetta python waiting to run.
Tullio

---

Since 2 days I have tried Python on several of my machines, the success is modest :-(
Too many tasks are still faulty (e.g. keeping running, but not using CPU, which is a waste).
Since I cannot, as someone else wrote above, babysit my computers just to find out whether a newly started Python task is okay or not, I will abandon Rosetta for the time being. Which is too bad, but I have no other choice :-(

You disable VirtualBox work on the details page of every one of your devices.

---

Another batch of work released, and only some of these error out straight away. Not great, but still better than all of them doing it.

+1
Seems that "h3_3stub" wus have problems

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x00007FF767908316 read attempt to address 0xFFFFFFFF

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x00007FF76B0A9D88

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x0000000000000000

Also these wus are NOT tested on Ralph

---

Some PcrV8MER wus crashed too.

BlueTooth76 wrote:

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.

There is no fix, but a workaround. See thread "Summary of issues with VirtualBox tasks", message 104802.