Hi there.

Credits here are ridiculous to compare with other project.

Then don't compare them.
Every project is its own ecosystem.

It seems to me that you are not interested in volunteers and their problems. It costs us a lot of money to run your research and if you choose to use Credit New or as some will say Credit Screw than that is a sure way of loosing customers. You have other choices to use. Look at other projects, talk to their Admin to see what is best for all concerned.

I've had enough of irresponsible people who complain about credits all the time!
This is about science, not about credit!
I like races as well (and am participating in the Formula Boinc sprint atm), but science has first priority.
I you don't like 'Credit Screw' then stop screwing with it and play Collatz on your GPU and something like PrimeGrid's GCW-Sieve or Numberfields on your CPU. And don't forget to add some instances of Goofy NCI.

---

- - - - - - - - - -
Greetings, Jens

Hi there.

Credits here are ridiculous to compare with other project.

Then don't compare them.
Every project is its own ecosystem.

It seems to me that you are not interested in volunteers and their problems. It costs us a lot of money to run your research and if you choose to use Credit New or as some will say Credit Screw than that is a sure way of loosing customers. You have other choices to use. Look at other projects, talk to their Admin to see what is best for all concerned.

I've had enough of irresponsible people who complain about credits all the time!
This is about science, not about credit!
I like races as well (and am participating in the Formula Boinc sprint atm), but science has first priority.
I you don't like 'Credit Screw' then stop screwing with it and play Collatz on your GPU and something like PrimeGrid's GCW-Sieve or Numberfields on your CPU. And don't forget to add some instances of Goofy NCI.

+1

If camb_legacy is offline, then what is this?
8/10/2018 1:10:53 AM | Cosmology@Home | No tasks are available for planck_param_sims and why is it not online?

If things don't get fixed soon, I think I will have to leave the project, because when you do come back online, your going to clog my system with a backlog of tasks because you have been offline so long, which in turn knocks all my other projects backwards.

If camb_legacy is offline, then what is this?
8/10/2018 1:10:53 AM | Cosmology@Home | No tasks are available for planck_param_sims and why is it not online?

If things don't get fixed soon, I think I will have to leave the project, because when you do come back online, your going to clog my system with a backlog of tasks because you have been offline so long, which in turn knocks all my other projects backwards.

Hi Greg, the camb_legacy tasks have been back online for a few weeks. Prompted by your message let me post a news item to avoid any confusion. The planck_param_sims app is an older app which we are unlikely to use again in the future (I will likely deprecate it soon, although up until somewhat recently it was possible we were going to run a few more of those workunits, but that now looks unlikely). In either case, when we add new workunits it shouldn't affect normal resource sharing between your other project, please let us know if anything weird is happening.

So...camb_legacy was unchecked for some reason in my preferences. So that is fixed.

I was not and am still not picking up any work from the camb_boinc2docker.

What projects are online and what one have you stopped supporting?

Just cam_legacy is online now?

I see two of your computers do not have have hardware virtualization support, which means they won't be able to receive camb_boinc2docker workunits. You have one which does have support but you need to enable it. Afterwards, you may also need to perform the steps here.

I wondered if that was the case. I installed a new version of VM but it did not connect. Will have a read on the links.. Thanks

I did not know about that one line in client state. Thanks
Now to grind through all the stuff I have already.

BTW - There is only 1 active computer. The older one on the bottom is the old version of windows on the dead SSD.

Thanks for the help!

I've been gone on vacation, and when I got back, only camb_legacy tasks have been running for at least the past few days. Virtualization was working before I left, and I confirmed in the computer description that everything is set up properly. Any advice about how to get camb_boinc2docker tasks to start downloading again?

Hmm, upon reviewing past tasks, it looks like nearly all of the camb_boinc2docker tasks had validate errors. Maybe the server stopped sending new ones because so few were validating?

I'll second your misery.
I've gone round and round with Vbox and even as far as going back to Vbox 5.2.8 and I get nothing but legacy tasks.

I see two of your computers do not have have hardware virtualization support, which means they won't be able to receive camb_boinc2docker workunits. You have one which does have support but you need to enable it. Afterwards, you may also need to perform the steps here.

Remove the Cosmology@Home project - did that
Shut down the BOINC client (from Advanced View choose the menu option Advanced->Shutdown Connected Client) - did that
Go to your BOINC folder and edit the file client_state.xml - went there
Remove the line which contains <p_vm_extensions_disabled> {{---BOINC rewrites that line at startup every time. No matter if I save the orginal client_state as a old file and save the edited one as default. I open the file and BOINC has written that line again.
Restart your BOINC client and readd the project - did that. See above.

Cool, removing the line from client_state.xml did the trick! I forgot that it keeps getting rewritten. Hopefully I won't have to edit it every time BOINC starts!

And the validation errors have stopped, too! Thanks, Greg!

From an old timer at LHC::

Try this

Go to regedit

Then HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ DeviceGuard \ Scenarios \ HypervisorEnforcedCode Integrity \ Enabled in the registry to 0

On the left side of that regedit page you will find all of this and slowly scroll through those steps and you will find it pretty easy.

(then you have to reboot of course and I tested this on a Win 10 machine)

This is what got my machine running normal again.

Since September 28, the camb_legacy validator is down again.
Meanwhile, the camb_kegacy work generator keeps generating...



(I am not affected myself, as I run camb_boinc2docker only.)

Edit,
BTW, the drop in PPD in Gridcoin's stats shows that the Gridcoin miners are on auto-pilot, and run 95 % camb_legacy : 5 % camb_boinc2docker. (Going by credit; going by CPU time it is an even lower percentage of camb_boinc2docker.)

As a followup:
Evidently, Marius gave the legacy validator a kick on October 5.



It worked through its backlog of WUs waiting for validation and finished it at October 10, ~22:00 UTC.

Needs to kick validator again. Have 62 WUs waiting validation and the status page shows validator for legacy is stopped.

---

This week's pending validation graph:



Looks like by the end of October 15, more people began to notice that the camb_legacy validator is not working, and turned away.

Transitioner backlog:



Yet, despite these troubles, contributors continue to download and process every single new task, fetching them the very minute one gets ready to send:



(Graphs courtesy to my team mate Kiska.)

Hello, I'm posting here because without credit, I can't post in Technical Support, and I don't know how else to report the problem I've come across.

The camb_2.16_x86_64-pc-linux-gnu app crashes immediately on a Debian stable computer with "SIGSEGV: segmentation violation". See the task in question.

It is a known error in other BOINC projects; it comes from vsyscall being forbidden in recent Linux kernels for security reasons. Indeed, the kernel message is more explicit:

camb_2.16_x86_6[32182] vsyscall attempted with vsyscall=none ip:ffffffffff600000 cs:33 sp:7ffef0c41488 ax:ffffffffff600000 si:0 di:7ffef0c414a0

While it can be mitigated if the cruncher reboots with the vsyscall=emulate kernel option, it lowers the computer's security (a bit). The proper long-term solution would be on the project side, to rebuild the app against a newer libc.

Even if camb_legacy isn't a priority, I thought you might want to know it doesn't work on recent Linux kernels at the moment.

Even if camb_legacy isn't a priority, I thought you might want to know it doesn't work on recent Linux kernels at the moment.

Good idea, but there is no one here. The server is running, but that is about all.

Good idea, but there is no one here. The server is running, but that is about all.

Thanks for the warning. You're confirming what I was afraid of seeing all the spam in the most recent thread.