LHC@home

You got trapped in 2 pitfalls.

1. sixtrack is also a subproject of LHC and therefore affected by the <project_max_concurrent> setting although it is not mentioned in your app_config.xml

But you managed it as you removed the <project_max_concurrent> entry.


2. You may check more than one subprojects in your preferences but you are not able to influence which of them sends WUs to your host.
Together with the "unlimited" setting your host is now flooded with WUs.

Until you have a clear picture of how many multicore ATLAS WUs you are able to run concurrently you may not check another subproject.

On my PC with 12 cores 24 threads, I can max out 64GB if there is too many ATLAS tasks.

I've seen it very high on my 10 core 20 thread machine too.

My other PC's with more ram I haven't seen so many concurrent ATLAS task.

I have the number of task set to 10 concurrent for 64GB to see if that is a bit better as 12 made the maxed one slow.

I have set cpu and tasks to no limit to try fix this issue I'm having... doesn't seem to be working :(

removed <project_max_concurrent>1</project_max_concurrent> all fixed :)

On my PC with 12 cores 24 threads, I can max out 64GB if there is too many ATLAS tasks.

I've seen it very high on my 10 core 20 thread machine too.

My other PC's with more ram I haven't seen so many concurrent ATLAS task.

I have the number of task set to 10 concurrent for 64GB to see if that is a bit better as 12 made the maxed one slow.

I have set cpu and tasks to no limit to try fix this issue I'm having... doesn't seem to be working :(

On my PC with 12 cores 24 threads, I can max out 64GB if there is too many ATLAS tasks.

I've seen it very high on my 10 core 20 thread machine too.

My other PC's with more ram I haven't seen so many concurrent ATLAS task.

I have the number of task set to 10 concurrent for 64GB to see if that is a bit better as 12 made the maxed one slow.

Some suggestions for possible next steps.


1. Check the logfile

After your WU is reported check the result on the LHC webserver (it includes a copy of your stderr.txt).
- The WU should be marked as "successful"
- the logfile should include lines like

Guest Log: <metadata att_name="fsize" att_value="54070367"/>
Guest Log: -rw------- 1 root root 54070367 Apr 27 14:01 HITS.10995533._009865.pool.root.1

If this is successful, go to step 2



2. Try 1 multicore WU

Leave "Max # jobs = 1", set "Max # CPUs = 2", set <avg_ncpus>2.0</avg_ncpus> and "read config files" in your client

OR

Leave "Max # jobs = 1", set "Max # CPUs = 4", set <avg_ncpus>4.0</avg_ncpus>, set <cmdline>--memory_size_mb 6000</cmdline> and "read config files" in your client

If this is successful, go to step 3



3. Try several multicore WUs concurrently

Increase "Max # jobs" step by step either with "Max # CPUs = 2" or "Max # CPUs = 4" and set your app_config.xml accordingly.
<max_concurrent>x
<avg_ncpus>y
<cmdline>--memory_size_mb zzzz
<project_max_concurrent>x

Don´t forget the "read config files" before the next WU download.



Always check the logfiles before you go from one step to the next.


At a certain point your host will start to produce errors because of
- faulty WUs -> check the message boards
- other projects also need resources
- a saturated internet connection -> how fast is it?
- a saturated disk IO -> a lot of users don´t check/believe this point
- not enough RAM -> test another combination of #WUs / cores per WU / RAM per WU
- not enough CPUs -> unlikely in your case :-)

This happens after every project reset until ATLAS (in this case) is known to your host through the first server response.
Nothing to worry about if you managed to load the app_config.xml before BOINC started the WU.
See number 8 of my list.

You may check the stderr.txt in the slots dir of the running WU.
If "Setting Memory Size for VM. (xxxxMB)" corresponds to your app_config.xml everything is fine.

Have you ever worked through Yeti´s checklist?
Fine.

Beside that you may restart the project with conservative settings.

1. Let your local WU cache get empty
2. Reset the project in BOINC
3. Update your VirtualBox software to the most recent version
4. Reboot your host
5. Set "Max # jobs = 1" and "Max # CPUs = 1" on the LHC website
6. Create the following app_config.xml

<app_config>
  <app>
    <name>ATLAS</name>
    <max_concurrent>1</max_concurrent>
    <fraction_done_exact/>
  </app>
  <app_version>
    <app_name>ATLAS</app_name>
    <plan_class>vbox64_mt_mcore_atlas</plan_class>
    <avg_ncpus>1.0</avg_ncpus>
    <cmdline>--memory_size_mb 5000</cmdline>
  </app_version>
  <project_max_concurrent>1</project_max_concurrent>
</app_config> 

7. Request a new WU from the project
8. Reload your configuration (must be done after you got the first WU and before the WU starts)
9. Check the result before you change your settings and request a new WU

Deleted app data file and still no change... closed and opened bionic etc

I suppose you still have tasks in queue, you already got before your changes.

Set in your preferences the # of CPU's also to 2 when you have 2 in your app_config.xml

Your hosts are hidden.
Expert users can´t check your logs.
You may change your preferences and make your hosts visible.

Your app_config.xml looks strange.
Is it due to the copy/paste or are there really lines like:

<?xml version="1.0"?>

-<app_config>


-<app>

Your setting

<avg_ncpus>2.000000</avg_ncpus>

overrules the website preference "Max # of CPUs = 24" except the server´s working set size calculation which is now 9000MB per WU.
Reduce the website preferences to not more than the value that you use in your app_config.xml.

A 24 core host would be able to run 3 8-core WUs (3x9000MB = 27000MB).
If you configure 4-core WUs 5800MB would be required per WU.
This would use 20 CPUs.

I have an I7 chip in my machine that is a 4 core processor and utilizes 8 threads, 2 for each processor. Each thread is capable of receiving 14 work units. Thus allowing me to receive 112 tasks when running a full load. Not bad for a 4 core processor! Pick

Yeah, seems to be some kind of faulty WUs ...

Have round about 40 or more of them