LHC@home

I assume they are the 217 people that have chosen to publish there statistics.

With LHC tasks the monitoring is itself a problem. They're not like other projects' tasks. Here "verified" doesn't always mean a successful result. With ATLAS, for example, you can spend thousands of hours crunching and have every result verify and think you've done a ton of useful work and then discover that in spite of the tasks verifying they did not return a HITS file and therefore did nothing but waste electricity. So monitor but do remember you sometimes need to look beyond what it says in the Status column in your results list.

Not sure. It depends on what your "other purposes" are. You haven't mentioned it and nobody has asked. It might make more sense to just forget about any LHC VBox app and just do Sixtrack and other projects' apps that can handle being suspended.

In the end it's your decision, your power bill and your CPU time so it only has to make sense to you.

dduggan47 wrote:

What happens is that 1 single core LHC project starts up and nothing else leaving 7 cores sitting on their hands. That's the behavior I don't understand. My little machine is not being fully utilized by BOINC in general or LHC in particular and the latter seems to be the bottleneck for some reason.

Boinc-client isn't good regarding MultiCore-Apps. You have to make a lot of micro-management to get things running together as you want. It is not a bad idea to run only 1 kind of MultiCore-Projekt, e.g. Atlas or others

1) Are these setting redundant?

Not exactly.
The website setting only affects multicore apps, in this case ATLAS and Theory.
It configures the #cores to be used by the BOINC client's reports/calculations, the working set size which your local client needs to estimate if an additional task can be started and the RAM setting for your vbox VM.
In addition it calculates the computer's GFLOPS value.

Some values (avg_ncpus, nthreads, memory_size_mb) sent by the server can be overwritten by an app_config.xml, others not, e.g. the working set size.

It's recommended to keep the website setting in sync with the app_config.xml.

2) Do they limit the number of CPU's for one task

The setting is for 1 task => 3 2-core tasks use a total of 6 cores

3) Do they have any effect on what else can run

Yes but it's your BOINC client that keeps track of your total ressources (cores, RAM, network access, ...)

I don't understand why they don't start...

Did you set any limits in your client GUI or via app_config.xml?

If I suspend LHC then BOINC immediately starts polling other projects ...

This is normal client behaviour and independent from LHC.

1) What did you change to allow 8 CPUs? Did you change it in your website settings? In the app_info.xml? Or both?
2) Did you create the app_info.xml? ...

@bronco
Again: Please, don't use "app_info.xml" in this context. It's "app_config.xml".

You are the earliest volunteer who is still returning results regularly so I thought the honor of being my first guinea pig should go to you. It's not much of an honor but it's the best I can do :)
Glad to see you're still dedicated after all these years.

... became aware of this today when I got an email from an admin letting me know.

Which admin and (more interesting as it may be helpful for others also) what was his/her suggestion?

Actually it was Bronco who answered above. His private advice was to come here and ask. :-)

Yes, it was me and I contacted you via PM not email. Also, I am not an admin (maybe). But those are minor details.

As you said in your op, you wanted to do more. I do too but at the moment I don't have additional computing resources to devote to this great project. What I do have is time and a suspicion that a great number of ATLAS tasks are returning no useful work in spite of the fact that they validate. So I created a script that grabs the host IDs, result IDs and result pages from a range of user IDs and analyses their ATLAS results (if any). It counts CPU and run time for all ATLAS tasks and CPU and run time for ATLAS tasks that don't return a HITS file and saves a list of user IDs returning "no HITters" to disk . I ran the script on user IDs from 67 to 10,000 and discovered that 7% of run time spent on ATLAS tasks is a total waste.

Then I reasoned that if I could get that 7% down to 1% it would get more even more additional work done than me buying another computer to devote to LHC (which isn't going to happen with RAM as expensive as it is and the huge requirements of LHC tasks other than sixtrack) . I composed a "form letter" to send to user IDs that are returning ATLAS results sans HIT files. So far I have sent that letter only to dduggan47 for a number of reasons:

1) I wanted to do at least 1 test run of the form letter to help gauge user reaction to it
2) I'm still learning how to automate sending the form letter
3) don't want to create a flood of angry users seeking advice and wondering why the hell this project validates useless results and leaves them with the impression that all is OK when it is not, a trickle of angry users seems easier to manage and perhaps more effective

... became aware of this today when I got an email from an admin letting me know.

Which admin and (more interesting as it may be helpful for others also) what was his/her suggestion?