LHC@home

Why don't people just join a REAL team instead of Gridcoin!

I have no sympathy for anyone who's a part of Gridcoin and it isn't working. BOINC should be "volunteer computing", not paid :/

I have step out until there have been some re-work on this and would like admins to take a look on this and project could be greylisted until it has been fixed

I think there will be no re-work of this matter ever. Here is why:

First of all the amount of work done by BOINC-Users is just a small fraction of all work being done by WLCG internally (although it's said to be comparable to a TIER-2 site). I think they just keep up the infrastructure for BOINC because it's free computing power to do simulations. And BOINC-Crunchers do nothing else but simulations for CERN (besides Sixtrack).

Secondly the credit issue just affects Gridcoin participants, which again are only a small fraction of BOINC-Crunchers. Normal BOINC-Crunchers don't really care about credits.

So why should they waste time (and therefore money) to fix something that only matters to a few cryptocurrency nerds? Don't get me wrong, i'm one of those nerds, but even i think this matter is not really important. I'm in for the science, not for the Gridcoins!

Tasks in progress 176513
Workunits waiting for validation 101240
Workunits waiting for assimilation 492
Workunits waiting for file deletion 113890
Tasks waiting for file deletion 200536

So what you're saying is that it allocates the ram and marks it used when it is in fact not using that ram? That's not a very good way of doing that. it caused my computer to start paging ram into my hard drive. Is there any way to make it NOT allocate 10gigs of ram? and only use what it needs?

According to the Grafana-Monitoring each CMS job runs a bit longer than 3 h.
At the end it uploads a result file of about 120 MB.

This numbers can be used to estimate how many CMS jobs can be run concurrently to reach 100 % upload saturation:

1 Mbit/s: 11
5 Mbit/s: 56
10 Mbit/s: 112
20 Mbit/s: 225
50 Mbit/s: 562
250 Mbit/s: 2812


@Gunde
Your computer list shows that you might had more than 3000 active cores during the last 2 days.
If this is correct and all of them ran CMS this may have saturated your upload.

Yes, I think 10629638 was the one that worried me. I did have a thought; do you have enough bandwidth to support as many jobs as you are running? There is a large amount of data downloaded at the start of each job (conditions database, etc.) and of course there is 70 MB or so of results returned at the end of the job. If you check through the message board, there are instructions on how to set up a caching proxy on a local machine{1} , which greatly reduces the amount of initial downloads that must come through the external network.

2020-12-20 09:40:29 (48180): VM state change detected. (old = 'Running', new = 'Paused')
2020-12-20 09:40:39 (48180): VM state change detected. (old = 'Paused', new = 'Running')
2020-12-20 09:51:31 (48180): VM state change detected. (old = 'Running', new = 'Paused')
2020-12-20 09:51:41 (48180): VM state change detected. (old = 'Paused', new = 'Running')

II restarted several times this VM and as you can see there hasn't been one single computation stopped => which proves that the start of a VM doesn't need 65% of a 3700X AMD cpu to start. Which in itself means that gunde was wrong by saying, yeah it's certainly the cpu cap blahblahblah. No it is not. And the computation stops at the start of CMS tasks (some of them not all of them), is not normal either, especially since those VM aren't as power hungry than a ubuntu 20.10 with GUI activated..

Putting a 100% cpu on project like that clogged the system

I restarted several times this VM and as you can see there hasn't been one single computation stopped

VM Heartbeat file specified, but missing

2020-12-22 11:33:20 (56104): Detected: Heartbeat check (file: 'heartbeat' every 1200.000000 seconds)
2020-12-22 11:53:34 (56104): VM Heartbeat file specified, but missing.

BOINC needs a quick and easy way to know if the project's app is still running so the app periodically touches a disk file in .../../slots/shared. The period is ~60 seconds and the file is named heartbeat. Touching a file either creates the file or, if the file already exists, updates the 'last accessed" datetime.

heartbeat is zero-length (ie. it's empty). You should be able to see heartbeat in file manager. If not then either your username doesn't have the required permissions or it doesn't exist. Watch it's last accessed datetime and notice that it increases by 60 secs every 60 secs.

So the VMwrapper (or possibly the VM itelf? ) touches heartbeat every 60 secs. BOINC periodically looks at heartbeat. At that point the possible scenarios go something like this:

1. If BOINC cannot see heartbeat then it can reasonably assume either the app/VM never started or the app/VM deleted heartbeat then died.

2. If BOINC can see heartbeat and it's last accessed datetime has incremented from the previous time it looked at heartbeat then BOINC can be reasonably sure the VM still lives.

3. If heartbeat exists but last access datetime has not incremented then BOINC could assume the VM lives but it's hung or it could assume it's dead but it didn't delete heartbeat before it died.

In your case it sounds like BOINC is terminating the task because it has no heartbeat and appears to be dead.

sudo apt-get remove boinc-client boinc-manager

sudo apt-get install boinc-client boinc-manager

sudo service boinc-client restart

sudo apt-get boinc-client boinc-manager

sudo apt-get install virtualbox-dkms