Rechenkraft.net e.V.

I've had RNA attached to all my BOINC computers for a few months and I've never gotten a WU. I'm running BOINC 7.10.2 with virtualbox64.
Any ideas why not???

There are only very few tasks available which usually all are out in the wild. They're all monsters which run for months or even years.
Sometimes a task crashes or is aborted due to users not knowing about the strange behaviour, necessary precautions and how to deal with all of them (to babysit the task, as Jacob would say), so a task may be available for some minutes before there are no tasks left again because of too many people wanting to get one.
Well, and sometimes a task gets finished as well, so the number of available ones decreases.
I've had RNA World attached to several computers for quite some time and never gotten a WU although I've been running a script to better my chances of getting one.

....which usually all are out in the wild.

Ah, ja, verstehe. Man muß also Großwildjäger sein, um derer habhaft zu werden. In freier Wildbahn....

Yes. You need to be lucky.

See the Server Status:
http://www.rnaworld.de/rnaworld/server_status.php

Currently there are only 97 tasks, that each take about 1-2 years to successfully complete, and when one fails, it is generally available for only 1-4 minutes before a user gets it.

You have to be lucky, to get one of these monsters.
And when you get one, you should babysit it like it is a family member :-p

Virtualization for one of my computers:

So far, I've found that the CPU supports both virtualization and hyperthreading.

There is a BIOS adjustment program that runs under Windows 10; it offers no way to change the hyperthreading and virtualization settings.

Unlike my last few computers, the boot procedure offers no second BIOS adjustment program that runs before choosing which operating system to boot.

The number of tasks BOINC will run at once indicates that hyperthreading is enabled.

No RNA World VM tasks on this computer so far.

This computer is faster than my other desktop computer, so I'd prefer to run any long VM task on this one if one becomes available.

How can I tell if virtualization is enabled?

Though a bit late, you may find this an easy way of checking...

https://www.trishtech.com/2017/08/check ... indows-10/

I currently have two monsters in the works...

Michael.

Nice. They can be very hard to get!
I have 13 that are taking FOREVER to get done!

If they are so long, why is it not limited to 1 per machine?

Why isn't the work size broken into smaller chucks?

Or why not have the work unit become a gypsy where it saves it's current work then ends after 7 CPU days, uploads the workstate to the server, gives that user's machine 7 days of credit, then has the server clone it and send down to a new machine.

The WU will roam about and hit various interesting machines as the 2 years go buy and a have quite a fanciful life.

Also, each WU wouldn't have a list of 70 abortions in its history...

mister.marmot hat geschrieben: ↑

02.05.2019 10:57

If they are so long, why is it not limited to 1 per machine?

Because nowadays there are enough machines that can easily process more than one WU per machine - even of these monster WUs.

mister.marmot hat geschrieben: ↑

02.05.2019 10:57

Why isn't the work size broken into smaller chucks?

For smaller WUs, one can simply unselect the long running tasks.

mister.marmot hat geschrieben: ↑

02.05.2019 10:57

Or why not have the work unit become a gypsy where it saves it's current work then ends after 7 CPU days, uploads the workstate to the server, gives that user's machine 7 days of credit, then has the server clone it and send down to a new machine.

The WU will roam about and hit various interesting machines as the 2 years go buy and a have quite a fanciful life.

Because this would require profound reprogrogramming of the system and won't give much advantage over what we already have in place.

mister.marmot hat geschrieben: ↑

02.05.2019 10:57

Also, each WU wouldn't have a list of 70 abortions in its history...

The long lists of abortions are actually mainly a result of participants not willing to read the project's compute requirements before starting to contribute. our project has various options to choose from in order to make contribution convenient. The long running VirtualBox tasks are only for experienced contributors with a more advanced hardware setup.

Michael.

Hello Michael,
I fully agree with you.
But I think the problem is on the WU
Someone who receive a WU with estimated running for month will cancel.
Who will wait , block a Core so long ?
And not knowing if it will not crash.
It is the same for all the project managed by xxxxx (I not write hyis name, if he read, he will know)

Only problem with "reichenkraft". On all project.
On Yoyo, some WU require 8 GIGA RAM to run !!!
On other , normal use, but takes about one day but checkpoint each 20% . It will say checkpoint depend of computing power !?

There are months, years complaints and nothing change from admin side.

Few WU, OK, but if admin reduce running time, or split, it will be profit for everyone :
Less cancel, fastest returned WU.
Instead of sending monster, enormous WU, split it
Who here is able to be assured that his host will have a so long time ???
At me, it seem projecvt admin not take care about us, creuncher.
Perhaps I am wrong. Perhaps not.
But in fact, the scientifics results do not arrive to scientist.
Sorry "Y" if you read this, you perfect know who I am.
To everyone else, stay with hope that we are able to crunch on a normal way

As far as I understood there are technical reasons which require those long tasks.
I'd be ready to take care of some of them btw.
Unfortunately they didn't come my way up to now.

There are or were other projects which field(ed) massive problems:
I have a stable environment for LHC now, but a lot of people don't want to run anything apart from SixTrack on that project because they think it's not too easy to set up for vm use.
Genefer-22 on PrimeGrid had lots of problems due to its massive runtimes before it was made GPU-only. I crunched one or two of those monsters on an oldish Core2Duo back then until they finished. Then I had to wait for validation through another cruncher.
I just found out the day before yesterday why most Gerasim tasks died on my Windows box.
Some projects don't even manage to stay up and running.
Some don't give work to any of my Linux, Mac OS or Windows boxes although there should be some available.
Several projects have work which runs better if you tweak an app_config.xml file.
At least one project should as promised take the time to give credits for the not validated, but necessary work which was done.
One should credits at all or shut down.
And every now and then some properly running projects run into trouble with new apps which behave only nearly as they're expected to.
Well, that's the Boinc universe.

So, if you just have problems on Rechenkraft maintained projects - be happy!