LHC@home

This computer has only 8 GB RAM.
Thus I would limit ATLAS to a 1-core or 2-core setup or run only SixTrack and Theory (also limited to 1-core or 2-core).
https://lhcathome.cern.ch/lhcathome/prefs.php?subset=project

Alright, I looked at the recent tasks on the LHC site, and the error is actually that.
I've put all projects to "No new tasks" mode, but I don't know how to proceed with the other steps. Could you please help me?
Thanks!

I am running only 1 core Atlas tasks on my both Linux hosts with only 8 GB RAM. But a GPUGRID task is running on two cores on both. Maybe it is needing less RAM. It does not use VirtualBox.
Tullio

---

Alright, I looked at the recent tasks on the LHC site, and the error is actually that.
I've put all projects to "No new tasks" mode, but I don't know how to proceed with the other steps. Could you please help me?
Thanks!

I must admit I only ran these Atlas alpha testing so it has been about 6 months so I may be just taking a wild guess again but I think what bronco is saying is to look in your VB Manager and see if your slots are full of old tasks that didn't get removed after finishing.

It looks like this



The main thing is you have to delete them one at a time but that part is easy.

You bring up your VB Manager and at the top left click on *FILE* and then *Virtual Media Manager* and that would be the page with the old slots data that would need to be *Removed* so you have those empty slots to use for new tasks.

If your Virtual Media Manager box is already clean then..........well it is 4am and maybe I should have just skipped this

@ MAGIC

Those entries in Virtual Media Manager are annoying but not really showstoppers.
They should disappear all at once when you reboot or restart VirtualBox.

Yes I wasn't sure if that former problem was fixed with these Atlas tasks but it did used to be a problem earlier this year so I thought I would give it a shot here again.

They used to be a big problem because they stayed there no matter if you did a reboot or just turned in the tasks.

(that is where that snap shot came from and I brought that here on some thread back on April 30th)

And even if it is working now it is good to have new members actually learn a few things that are not explained much and if they were not running VB tasks back when we started them back in 2011

(I see she has one Atlas running right now)
https://lhcathome.cern.ch/lhcathome/results.php?hostid=10541335

Ok goodnight

Thanks a lot for the help!
So, I opened the window you screened, and there are no files that needs to be removed, so that's probably not the problem. I noticed though that there are some other VM inside the VB manager, and these are inaccesible, and in the details they all say this:

Result Code:
E_FAIL (0x80004005)
Component:
MachineWrap
Interface:
IMachine {b2547866-a0a1-4391-8b86-6952d82efaa0}

I don't know if it's related to my problem but I don't remember having them when I first installed BOINC.
Anyway, yes, there is one ATLAS request computing, and it hasn't given any problem so far.

Those entries should be removed from VBox Manager as they are remains from older crashes.

I think what bronco is saying is to look in your VB Manager and see if your slots are full of old tasks that didn't get removed after finishing.

No, I was suggesting to open Windows file manager, navigate to the BOINC data folder and delete the slots folder. If that can be done via VBox Manager then that's good enough but I doubt VBox manager sees or cares about anything other than *.vdi files so if there is other junk lying about VBox will ignore it.

Those entries should be removed from VBox Manager as they are remains from older crashes.

So I'd better delete them, right?

I've done a research inside my computer, and inside the folder named BOINC there are just some text files..

Anyway, yes, there is one ATLAS request computing, and it hasn't given any problem so far.

Maybe I missed it but It sounds like you haven't actually changed anything. In that case you can expect the currently running task/request to crash too. You might get lucky for a few tasks but eventually they will crash.

The stderr output for the recently crashed tasks shows they are stopping and starting frequently. That's not good. VBox tasks need to run start to finish uninterrupted if you want to minimize failures. The most likely cause of the frequent stop/starts is that in your preferences you have the "Suspend when non-BOINC CPU usage is above __ %" set too low. I have mine at 95% and all my non-BOINC apps remain responsive but that's just me. I don't usually run CPU intensive apps, just a web browser, a text editor and other low CPU usage apps.

Also, with only 8GB RAM you definitely need to consider running ATLAS on fewer cores. Stderr output shows you've been running 4-core ATLAS tasks which is likely too much for 8GB RAM. If you have an aching need to keep all 4 cores busy all the time then you should consider sticking with Theory and Sixtrack tasks.

I've done a research inside my computer, and inside the folder named BOINC there are just some text files..

Then you are not looking in the BOINC data folder. Inside the BOINC data folder there will be a folder named slots. But now that you have another task running you don't want to delete the slots folder because doing so will crash the running task. Delete slots folder only when there are no tasks running and the cache is empty.

The path to the BOINC data folder is listed near the top of the Event Log. If it's not there then it's because it has been pruned off to keep Event Log down to a reasonable length. In that case restart the client and check Event Log again.

I don't have problems in BOINC using most of the cores, I actually need not much. I had lowered the percentage of memory available because other projects would make non-BOINC apps non responsive, but now I set it at 85% when I'm using the computer and 95% when I'm not, and like right now ATLAS is running.


Right now the only thing that seems to me I can do is remove the inaccesible machines in the VB manager.

I don't have problems in BOINC using most of the cores

That works for most projects but ATLAS requires much more RAM than other tasks. You are living near the edge with 4-core tasks. Sometimes you will get lucky and not go over the edge but frequently you will. If you can live with that then OK.

Right now the only thing that seems to me I can do is remove the inaccesible machines in the VB manager.

Right, and that may be sufficient. Or it might not be sufficient. If you can live with "maybe, maybe not" then that's good.

I completed and validated two 2 core Atlas tasks on my Windows 10 PC. As usual on this PC with 4 cores and 22 GB RAM the stderr.txt file does not show any HITS file. I've started a one core Atlas task on my HP Linux laptop with its new Leap 15.0 (old 42.3) OS which, as I read on the register.co.uk has been optimized to connect to Microsoft Azure Cloud, which I certainly won't bother to do. But SuSE and Microsoft are cooperating.
Tullio

---

I completed and validated two 2 core Atlas tasks on my Windows 10 PC. As usual on this PC with 4 cores and 22 GB RAM the stderr.txt file does not show any HITS file.

No HITS file mentioned in stderr output but you can use their PandIDs to verify that they produced a HITS file, see https://bigpanda.cern.ch/jobs/?pandaid=4030194846,4030244989

Thanks but when I try to connect to your link Firefox says that the connection is not secure and refuses to connect.
Tullio

---

I think the reason Firefox says the URL is not secure is because the site does not have a proper security credential. However, as you can see from the URL, it is of the same domain as this website... cern.ch. It is secure and legitimate. I am confident admins here will vouch for its legitimacy.

You can tell Firefox to make an exception and proceed with the connection. I forget the exact procedure but I think it begins with clicking the "More information" link and then maybe tick a box that says you have read the warning and are aware of the risk but you are confident the site is secure. There might be an additional "Are you sure?" thing to click too. Somewhere along the way you can click something like "Remember this exception" and then you don't have to jump through all the hoops again next time.

After all the above you also need to register a username and email address. If you accept their cookie you never have to login again. I use the site frequently and have never received an email from them or a promotion or anything. It's just their way of keeping the bots out, I guess.

I confirm the bigpanda.cern.ch site is legitimate and we will not send you spam after you register :)

To avoid the browser security warnings you can import CERN's CA files as described here. After this your browser will trust any of CERN's secure sites.