For Pete's sake.

Rosetta 4.21 is nothing new, it was released only 7 days after Rosetta 4.20, almost 2 years ago.

---

Grant
Darwin NT

What is the difference between the two?
If .21 is "newer" then why are we are .20?

oh ok.....kind of wondered why it kept sending despite aborting.

Which leads me to the question I posted.
Whats the difference?

What is the difference between the two?
If .21 is "newer" then why are we are .20?

It's not newer, it was just a fix for 4.20 on 32bit systems.

---

Grant
Darwin NT

oh ok.....kind of wondered why it kept sending despite aborting.

If you do it enough, you'll end up with only getting 1 Rosetta 4.20 Task per 24 hours until you start returning Valid work again (just under another 200 to go to reach that point).
But just leaving it be & let the BOINC Manager timeouts limit the amount you get is just a whole lot easier. And if we do ever get any Rosetta 4.20 work we can process again, you'll be able to get a full load on your first request instead of having to build up how many you can get every 24 hours over several days.

---

Grant
Darwin NT

Which leads me to the question I posted.
Whats the difference?

IIRC, Rosetta 4.20 is the regular modern Rosetta that requires a 64bit OS and CPU. 4.21 was released specifically for older systems on 32 bit. I remember there being talk about phasing out 32 bit Rosetta tasks, I think the consensus was that that probably wasn't a good idea so 4.21 was released. I do not know about any other differences.

In other words, 4.20 requires a 64 bit system, 4.21 requires a 32 bit system.

Anyways, "Intel x86 compatible" has nothing to do with Intel vs AMD, the same way "AMD x86_64 compatible" has nothing to do with AMD. They basically mean garden variety X86-32 and X86-64, respectively.

I have given up on manualy aborting tasks , it takes longer than `just leave them to it`
and any way , it don't like me any more . . .
20/02/2022 00:33:22 | Rosetta@home | This computer has finished a daily quota of 37 tasks
and so little time later
20/02/2022 01:13:43 | Rosetta@home | This computer has finished a daily quota of 1 tasks
and I have left it alone today .
never mind I will save on electric

I haven't got my head around what the specific issue is with rb tasks crashing out, but I do see people reporting problems with those too.
If someone describes the rb issue to me in a way I can pass on, I'll follow up with that too.
Is it much the same as movingstubs tasks or are they crashing on Ubuntu as well?

I've finally found some RB tasks on this PC and, while they haven't finished, they're at a few hours in without crashing yet.
The problem ones you guys are posting are rb_02_14 or rb_02_16 and the ones I have are rb_02_18
If the project was shut down for a while and came back up shortly after, could it be a fix went in? I notice a half million drop in the queued jobs on the front page.

Or I'm speaking too soon. I'll see in 5hrs more time

I didn't get a chance to look at them but rb_02_18 tasks <seemed> to complete successfully.
Which would be great, except I haven't seen any further rb tasks to run since <sigh>

It looks like these movingstub tasks are going to be allowed to error out, seeing as they take up so very little user runtime. A project problem more than ours.
Without having had any reply, it may be they've taken the view that linux systems will continue to run them successfully and Windows systems will error out and they get what they get. That's happened before.
In the meantime, the queue that started off at 4.4m (inc 2.2m pythons) is now down to 2.8m (inc 2.2m pythons) so we're ~75% through them and it won't be too long before they're wiped out anyway.
I know that's not satisfactory, but it may be how this episode turns out

---

Warning! RAH is sending out moving stubs in bulk now. I just aborted over 130 of them in the last 5 minutes
Now setting RAH to no new tasks.
I have only 1 python running.

UNREAL!

Despite the twitt of Rosetta@Home account, i continue to receive "movingstubb" wus (and continue errors)

---

it seems that the server side of Boinc has decided alone to use the 32Bits app with my W7 64Bits OS because of the hudge amount of bad tasks, an automatic process to eradicate a bad app ?

but 4.20 64b and 4.21 32b are not bads applications ...

Warning! RAH is sending out moving stubs in bulk now. I just aborted over 130 of them in the last 5 minutes
Now setting RAH to no new tasks.
I have only 1 python running.

UNREAL!

Despite the twitt of Rosetta@Home account, i continue to receive "movingstubb" wus (and continue errors)

One, because its the weekend and two as Sid pointed out a few posts below, it is possible that since the linux ones run just fine they will just let the windows ones go through and error out. After 2 or 3 errors then its a dead task.
Either they don't care or don't have time or understanding on how to purge these tasks.

The problem ones you guys are posting are rb_02_14 or rb_02_16 and the ones I have are rb_02_18
If the project was shut down for a while and came back up shortly after, could it be a fix went in? I notice a half million drop in the queued jobs on the front page.

Or I'm speaking too soon. I'll see in 5hrs more time

I didn't get a chance to look at them but rb_02_18 tasks <seemed> to complete successfully.
Which would be great, except I haven't seen any further rb tasks to run since <sigh>

Seems like I forgot what PC they ran on. It was the PC I just left and the rb_02_18 tasks <did> run successfully.
Still haven't received any others

It looks like these movingstub tasks are going to be allowed to error out, seeing as they take up so very little user runtime. A project problem more than ours.
Without having had any reply, it may be they've taken the view that linux systems will continue to run them successfully and Windows systems will error out and they get what they get. That's happened before.
In the meantime, the queue that started off at 4.4m (inc 2.2m pythons) is now down to 2.8m (inc 2.2m pythons) so we're ~75% through them and it won't be too long before they're wiped out anyway.

Now down to 2.2m and none unsent, so looks like those left are all Python tasks. No more to come down - just returning 300k duff tasks (except for those running linux).
Until next time...

---

The problem ones you guys are posting are rb_02_14 or rb_02_16 and the ones I have are rb_02_18
If the project was shut down for a while and came back up shortly after, could it be a fix went in? I notice a half million drop in the queued jobs on the front page.

Or I'm speaking too soon. I'll see in 5hrs more time

I didn't get a chance to look at them but rb_02_18 tasks <seemed> to complete successfully.
Which would be great, except I haven't seen any further rb tasks to run since <sigh>

Seems like I forgot what PC they ran on. It was the PC I just left and the rb_02_18 tasks <did> run successfully.
Still haven't received any others

It looks like these movingstub tasks are going to be allowed to error out, seeing as they take up so very little user runtime. A project problem more than ours.
Without having had any reply, it may be they've taken the view that linux systems will continue to run them successfully and Windows systems will error out and they get what they get. That's happened before.
In the meantime, the queue that started off at 4.4m (inc 2.2m pythons) is now down to 2.8m (inc 2.2m pythons) so we're ~75% through them and it won't be too long before they're wiped out anyway.

Now down to 2.2m and none unsent, so looks like those left are all Python tasks. No more to come down - just returning 300k duff tasks (except for those running linux).
Until next time...

I killed the remaining 33 I had on my system. Good riddance!
Now the other projects need to get some work done so maybe later I get python back.

Oh..now I am insulted...the damn system knocked me off python for some reason (to many aborts of 4.2?) so I had to connect again. Can't they do anything right?

Despite the twitt of Rosetta@Home account, I continue to receive "movingstubb" wus (and continue errors)

One, because it's the weekend and two as Sid pointed out a few posts below, it is possible that since the linux ones run just fine they will just let the windows ones go through and error out. After 2 or 3 errors then it's a dead task.
Either they don't care or don't have time or understanding on how to purge these tasks.

It doesn't seem to be a case of that imo.
It's not that there's anything wrong with the tasks - just that they won't run on Windows machines but will run on Linux.

So how can they select "bad" ones to delete? They can't.

The selection of "bad" tasks is very efficient.
Allow Windows machines to download them and they're all rejected after 20 seconds.
Linux machines run them successfully to completion.
A perfect solution. All the machines that can run them do. All the ones that can't, don't.

The price paid is in bandwidth of Windows users, that's true, but nothing more.
I don't personally consider people's frustration to be worth a second thought

---

| Rosetta@home | Started download of AIMNet_minimization_python_project.py
AIMNet - Atoms In Molecules Neural Network Potential

This repository contains reference AIMNet implementation along with some examples and menchmarks

Accurate and transferable multitask prediction of chemical properties with an atoms-in-molecules neural network

Anyone got details on this?
I am just looking fast...not digging around yet.

Do you have problems with download speed?
My download speed is 595 KBps

Well that's the end of that batch, 50% or more of which were errored out.
What a waste.

---

Grant
Darwin NT

Are the vbox tasks limited as to how many can run concurrently. Can only get 17 to run at the same time. All others are in "waiting to run" status in BOINC. No app config file in the projects directory.

.Can you try to change use at most memory setting in computing preferences > disk and memory?
You have hidden your computers so i can't see them.