The created VMs still have the same Hard Disk and RAM set up as before. 8Gb HD and 6Gb RAM.
All tasks I had running had to be aborted. They weren't using any cpu cycles.

Is anyone successfully completing one?

Mine are saying 2.79 GB of RAM and using barely over 56 MB each.
I've completed 4 so far on my laptop.


I see you got a few done. OThers were aborted. If they weren't using CPU cycles, it's possible they were some of those that hang for hours and hours.

---

What Boinc reports and what the VM is created with is two different things. I get about the same results as you looking at the Boinc task properties.
All the successful tasks were the previous Python versions. Started with "boinc_cages_IL_"

I haven't got a single, newer one to run yet. they all hang and when I call up the VM's screen the last line is
"Intel MKL FATAL ERROR: Error on loading function mkl_lapack_ps_mc3_dsytrf_l_small."

If you call up Virtual box and look at a VM, is you last line like that on the monitor? You just go to Machine - Detach GUI to close it afterwards.

I see VB reports 6144 MB of base memory.
No, I don't have that line when I open the VM on either of the 2 Pythons that seem to be running fine.

---

I've got one here that's saying 6GB, but also one that has 10200MB! And 20GB of disk space...

---

I'm still running 2 Pythons and Rosetta is using 24 GB of my SSD.

---

snip...
Now then what can I meddle with next . . . .
How about going to `vbox64_mt` and setting the default cpu count to two and then half the default run time
that would offset the memory use and use more cpu`s , hmm ;)

You'd better check if Oracle provides vbox64_mt and whether the Python tasks are able to use it before doing much with that.
The Python tasks now only reserve 2.79GB of memory each, at least for Windows 10, so the project staff HAS found a way to control the amount of memory reserved.

cosmology@home has been using `vbox64_mt` for a few years on its vbox work

I see there are still a lot of big Python _1 tasks in the pipeline, resends that will take a while to clean up, that still demand big memory, and stop the python mini`s running

snip...
Now then what can I meddle with next . . . .
How about going to `vbox64_mt` and setting the default cpu count to two and then half the default run time
that would offset the memory use and use more cpu`s , hmm ;)

You'd better check if Oracle provides vbox64_mt and whether the Python tasks are able to use it before doing much with that.
The Python tasks now only reserve 2.79GB of memory each, at least for Windows 10, so the project staff HAS found a way to control the amount of memory reserved.

cosmology@home has been using `vbox64_mt` for a few years on its vbox work

I see there are still a lot of big Python _1 tasks in the pipeline, resends that will take a while to clean up, that still demand big memory, and stop the python mini`s running

Good. The other problem is whether the Rosetta python tasks are written to know how to use it.

Some needs to open the download hose some more.
2GB files and in 5 minutes it has downloaded on 38.75% of the vdi file.
That's slower than a handicap snail!
3200 KBs? for 2 gigs! gees!

Mine downloaded at around 2500 kbps last night. Which is fine, I'm patient lol.

I've noticed the amount of ready to send Pythons has been decreasing for a while now.
Currently at 1815, 2 hours or so ago it was at 3730. Wonder if there's an issue.

---

Now to add insult. First 5 files, then the next 4 files and the next 4 files after that all have failed to download errors!!!

What now?

Just added rosetta to a new machine and all w/u have failed with download errors.
it says:-
Giving up on download AIMNet_minimization_python_project.py:permanent HTTP error.

It downloaded (v.slowly) the 2 gig file ok.......

---

Now to add insult. First 5 files, then the next 4 files and the next 4 files after that all have failed to download errors!!!

What now?

One thing to do is to wait for another try at downloading those files.

Nothing but download errors now with the new vdi file

<core_client_version>7.16.6</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
<file_name>AIMNet_minimization_python_project.py</file_name>
<error_code>-224 (permanent HTTP error)</error_code>
<error_message>permanent HTTP error</error_message>
</file_xfer_error>
</message>
]]>

No size on the file when it actually exists.
-rw-r--r-- 1 boinc boinc 0 Dec 1 18:56 AIMNet_minimization_python_project.py

Something`s broken the server [waznt me . . . ]
As of 2 Dec 2021, 0:00:15 UTC [ Scheduler running ]
Total queued jobs: 2,163,843
ready to send 0
so its nufink 2 do 4 a wile

Don't they even check their stuff before dropping it on the server?
Really doesn't seem that way.

They are sending me stuff (pythons), but it is somewhat futile.
A significant number either fail with "0 CPU", or else "Vm job unmanageable".

That should have been taken care of before they even started with the pythons.
But then they might have had to listen to feedback from the crunchers.

---

I haven't received any new tasks since November 28. Are there any issues right now with the task server?

There are few of the standard Rosetta app tasks available.
There are plenty of the Python Rosetta tasks, though. But you need to install Virtualbox in order to run those.

---

I haven't received any new tasks since November 28. Are there any issues right now with the task server?

No...just very small limited batches of 4.2 stuff.
The focus seems to be on Python projects now.

Something`s broken the server [waznt me . . . ]
As of 2 Dec 2021, 0:00:15 UTC [ Scheduler running ]
Total queued jobs: 2,163,843
ready to send 0
so its nufink 2 do 4 a wile

There may be 2 million queued, but they are not ready to be released yet.
You can look to the right top and you will see: Tasks ready to send 5007
And then below left is the breakdown:
Rosetta 9 69053 6.93 (0.24 - 41.66) 2284
Rosetta Mini 0 0 --- 0
rosetta python projects 5001 21761 4.76 (0.01 - 36.33) 1457

Which does not match as the total here is 5010.
But what is 3 jobs in the big picture anyway.

And at 2300 UTC I was getting lots of download errors, so maybe they pulled the tasks to repair the problem.
I have not looked at my event log to see when I got my first new 4.2 and Python. But I have those now.