LHC@home

2019-12-29 12:47:43 (8476): Required extension pack not installed, remote desktop not enabled.
If you have Win 10pro or a Linux, you should install Virtualbox extension pack.

Hi Droople,
Atlas have a small window to finish the tasks (max.7 Days).
Some time it is shorter needed from Cern.
Your tasks started from a other User and finished. So this tasks from you are obsolet.

Dear All,

I got several 0 (0x00000000) Error on 300.02 Theory Simulation (vbox64_theory),not sure if anything caused this.

.
.
2019-12-20 16:22:43 (70060): VM state change detected. (old = 'Running', new = 'Paused')
2019-12-20 16:23:04 (70060): VM state change detected. (old = 'Paused', new = 'Running')
2019-12-20 16:23:23 (70060): VM state change detected. (old = 'Running', new = 'Paused')
2019-12-20 16:23:33 (70060): VM state change detected. (old = 'Paused', new = 'Running')
2019-12-20 16:50:53 (70060): VM state change detected. (old = 'Running', new = 'Paused')
2019-12-20 16:51:03 (70060): VM state change detected. (old = 'Paused', new = 'Running')
2019-12-20 16:52:54 (70060): VM state change detected. (old = 'Running', new = 'Paused')
2019-12-20 16:53:04 (70060): VM state change detected. (old = 'Paused', new = 'Running')
2019-12-20 16:58:55 (70060): VM state change detected. (old = 'Running', new = 'Paused')
2019-12-20 16:59:05 (70060): VM state change detected. (old = 'Paused', new = 'Running')
2019-12-20 17:06:58 (70060): VM state change detected. (old = 'Running', new = 'Paused')
2019-12-20 17:07:08 (70060): VM state change detected. (old = 'Paused', new = 'Running')
2019-12-20 17:37:00 (70060): VM state change detected. (old = 'Running', new = 'Paused')
2019-12-20 17:37:50 (70060): VM state change detected. (old = 'Paused', new = 'Running')
etc etc

Virtual Machines don't like this.
It's maybe caused by your BOINC preferences. Have you ticked "Suspend when non-BOINC CPU usage is above ... % (untick that or set it to 100%)
or a very low number for "Switch between tasks every ... seconds"
When you want to reduce cpu-usage you could keep a core idle by setting "Use at most ...% of the CPUs" lower
or set "Use at most ...% of CPU time" lower.

I just think its unfair for the people who finish the WU before the deadline but only a bit later than other people. Not all the computers are running and connecting to Internet and crunching LHC@Home 24 hours.

It wasnt very long ago that I joined this project, and I must admit that initially I felt the same way you do. It just seemed totally unfair that after waiting SO long for WUs to crunch, that when I finally get some, it seems that most get aborted before my clients barely get started on them.

I dont feel that way any longer. Why, you might ask? Well, not long ago, while I was in the process of composing a post for a new thread(not unlike the first in this thread), I had an epiphany. I suddenly realized that, it really shouldnt matter to me how may WUs I crunch and get credit for. The important thing is that the work just gets done period. It doesnt matter if my total credit is 1 or 1 million. For me, its not a contest, because the only \"winner\" should be the LHC and the scientists who have devoted their lives to the science.

By participating, I am offering my available resources to the project. If they are used, great! If they are not, thats OK too. Either way, I am still participating and feel like I am a part of something very important thats much bigger than me.

Leevis

Hi Leevis

I understand what you mean, as long as you can contribute something to the project, you are satisfied.

But please don\'t forget crunching needs electricity, and in Australia, the power stations burn coal(85%). LHC@home aborted the results, this means some CO2 was generated for nothing.

It\'s not sustainable.

Cheers

They are canceling only redundant results that have not started crunching. If they haven\'t started then next to 0 CPU time and electricity has been spent on them. It\'s the tasks that are redundant but don\'t get canceled because the host has already started them... those are the results that are wasting CPU time and electricity. If hosts would contact the server more often then more redundant tasks would get canceled. The project managers can direct hosts to contact the server more frequently but they are not doing so.

There are BOINC options you can set on your end (the host end) which will tend to cause your computer to contact the server more often. More frequent contact increases the odds of your computer receiving a cancel order before it starts crunching a redundant task rather than after.

I just think its unfair for the people who finish the WU before the deadline but only a bit later than other people. Not all the computers are running and connecting to Internet and crunching LHC@Home 24 hours.

It wasnt very long ago that I joined this project, and I must admit that initially I felt the same way you do. It just seemed totally unfair that after waiting SO long for WUs to crunch, that when I finally get some, it seems that most get aborted before my clients barely get started on them.

I dont feel that way any longer. Why, you might ask? Well, not long ago, while I was in the process of composing a post for a new thread(not unlike the first in this thread), I had an epiphany. I suddenly realized that, it really shouldnt matter to me how may WUs I crunch and get credit for. The important thing is that the work just gets done period. It doesnt matter if my total credit is 1 or 1 million. For me, its not a contest, because the only \"winner\" should be the LHC and the scientists who have devoted their lives to the science.

By participating, I am offering my available resources to the project. If they are used, great! If they are not, thats OK too. Either way, I am still participating and feel like I am a part of something very important thats much bigger than me.

Leevis

THx for all replies.

Sure is better to speed-up the server-side; when 3 sucess results are returned, then the other work is not necessary.

But you can do this by sending out only 3 WU !!
(or 4 , for assurance, when one fails)

The problem with LHC tasks is that the first 3 Success returns frequently fail to match. Frequently, even a 4th Success result fails to match. And frequently 1 or more of the first 3 returns Compute Error. That happens so frequently that they find it is faster just to send 5 results at the beginning, in other words, to use Initial Replication = 5 (IR = 5).

More precisely, it was faster to use the IR = 5 strategy when they were using the old server code. In fact, that was the only speed up strategy possible with the old server code. The new server code they recently installed has new features and capabilities that make possible new strategys where maybe they can have IR = 3 and complete the batch of work just as quickly as with IR = 5. But that strategy also includes implementing some as yet undetermined combination of these new features:

1) limiting crunchers to having no more than X tasks per CPU in their cache, to spread the work out over more hosts
2) the server keeping a list of fast reliable hosts to which additional tasks will be sent if 1 or more of the first 3 tasks fails or the first 3 don\\\'t achieve quorum.
3) possibly reducing the deadline
4) making BOINC client version 5.8.16 a minimum requirement to participate in the project
5) other new features I have forgotten at the moment

Using those new features, other projects that were forced to use IR = 5 a few years ago have found they are now able to reduce IR to 3 and still finish the batch quickly but they likely had to rewrite some/all of their verifier/assimilator/feeder/transitioner scripts to accomplish all that. That takes time and money. We can only hope that LHC will find a way to incorporate some of those new features into their strategy, if they can. Canceling redundant tasks is a good start.

Finally servers accepting results. But credit don't granted because of "Task was reported too late to validate". :(
All tasks was finished more than week ago.
Why report deadline wasn't increased?