LHC@home

After deleting many really old results from 2013 until March 2017 (was meant to
be December 2016) it seems many Tasks have been aborted. A full analysis
and report will be posted. No action required by volunteers. Eric.

---

Apologies all round; it was MY fault. My MySQL query was missing
and AND clause on server_state=5... Sorry about that. Eric.

---

Were the work units recycled back into the too be distributed stack for reassignment ?

Bill F

---

In October 1969 I took an oath to support and defend the Constitution of the United States against all enemies, foreign and domestic;
There was no expiration date.

I encountered an other problem by crunching LHC@home:
Some WU with more CPU stoped after around 10 minutes. The messages where:
-waiting for memory
-reported:waiting for hyperwisor....

So i abandonned this files because they couldn't be runned until the end like other WU
I had regulary such problem or similar when i was crunching by LHC@home
I had six track or atlas simulation
Every atlas simulations failed

I encountered an other problem by crunching LHC@home:
Some WU with more CPU stoped after around 10 minutes. The messages where:
-waiting for memory
-reported:waiting for hyperwisor...

I have been getting that message more than more, and not just from LHC@Home. Simply let it go, and eventually the BOINC scheduler will run the job.

I saw one of my LHC@Home jobs get aborted, I never knew projects could do this remotely.

---

I gived the answer upon the observation on my screen not to bring the world to worry but to help the engineer to understand the origin of the problem.
A little peace and love in this world and avoid to scratch the hair of the other one. Usually the enginneer don't have to much hair on the head because the have enough problem to solve each day. Sometimes they are using her own head to be quiet if you understand what i mean!

Best Regards

Guy PFLIEGER

I had the same problems, it would come and go but eventually became very severe affecting 100% of the LHC tasks. I resolved my issues by modifying the "Disk and memory" settings under "Computing preferences" in BOINC. I increased the "Use no more than x GB" value and decreased the "Leave at least x GB free" value. My computer has worked perfectly since allowing additional resources for BONIC projects.

---

in the internal error treatment of the error must be noticed every parameter of the computing machines
-Software
-boinc version
-state of the register
-allocated memory
-unallowed operations
-state of the memory
-name of the WU
...

Guy PFLIEGER

actually i don't have a job but i have ideas

Best regards

Guy PFLIEGER

Sorry,

this is a NEWS thread!

For crunshing please write in number crunshing.

Hi everybody out there. I'm absolutely beginer on LHC@home. I'v started about 1 month ago. After recieving the message "VB not installed" i did it, with extension. I didn't configured anything.(Must i?) Now nearly all Atlas Simulations reports "Berechnungsfehler" = computingfailture. Is it a failture of my machine or is it a failture in the script of the WU ? I'm running BOINC on 3 of 4 cores and adjust few times the amount of memory and disc space use so i don't need to pause while working with other software.
Funny is also that after this failture the "progress" is on "100.000%". Most simulations are running not more then 20sec. Only 1 was more than 3h "on the run".
Can somebody tell me what to do, if necessary?
(sorry about my english!)

I believe your memory is too small. Try running on one core only, then on two and see how it goes. I am running on 2 cores on a Windows 10 PC with 22 GB RAM and on one core on two Linux boxes with 8 GB RAM.
Tullio

VirtualBox 5.2 is not 100% compatible with vboxwrapper used by the ATLAS project.
Try downgrading to 5.1.30 https://www.virtualbox.org/wiki/Download_Old_Builds_5_1

I am using 5.2.2, both on Windows and Linux in Atlas tasks.
Tullio

VirtualBox 5.2 is not 100% compatible with vboxwrapper used by the ATLAS project.
Try downgrading to 5.1.30 https://www.virtualbox.org/wiki/Download_Old_Builds_5_1

You might have something there.

My Windows 7 Pro machine was getting (on ATLAS WU's only) a constant stream of "Postponed: VM is unmanageable" errors on 5.2.0 and 5.2.2 so after downgrading to 5.1.30, there have been no more of those errors in 3 days.

You might have something there.

My Windows 7 Pro machine was getting (on ATLAS WU's only) a constant stream of "Postponed: VM is unmanageable" errors on 5.2.0 and 5.2.2 so after downgrading to 5.1.30, there have been no more of those errors in 3 days.

The same may happen with the CMS-subproject.

ATLAS and CMS are using wrapper version 26196 and that conflicts with VBox 5.2.
Theory (wrapper 26198ab5) and LHCb (wrapper 26198ab7) probably will work together with VirtualBox version 5.2.

ATLAS and CMS are using wrapper version 26196 and that conflicts with VBox 5.2. ...

well, what concerns CMS I can tell that on my system, it works with VBox 5.2; although the third line in stderr reads
Error creating VirtualBox instance! rc = 0x80004002

However, this does not seem to be a real problem - all CMS tasks are completed properly.

For ATLAS I cannot tell, because for memory requirement reasons I don't run ATLAS on this machine.

Atlas tasks run on my Windows and Linux PCs with VBox 5.2.2. This is probably due to the fact that the kernel is still 4.4 on the Linux boxen. Windows 10 is being update constantly by Microsoft. I only have problems with SETI@home GPU tasks running on it, while Einstein@home GPU tasks run perfectly.
Tullio

ATLAS and CMS are using wrapper version 26196 and that conflicts with VBox 5.2.
Theory (wrapper 26198ab5) and LHCb (wrapper 26198ab7) probably will work together with VirtualBox version 5.2.

Atlas native App for Linux use wrapper_26015_x for vboxwrapper.

I only have problems with SETI@home GPU tasks running on it, while Einstein@home GPU tasks run perfectly.
Tullio

But this cannot be related to any VM version, since these two projects don't use VM