LHC@home

Yes, we're working on it, but it takes time. Currently we have some two-core and some 4-core jobs in the queue. These will only run in -dev. Let us know how you get on. I'll put some single-core jobs up as well, so people not in -dev can get some work too.

---

Yes, we're working on it, but it takes time. Currently we have some two-core and some 4-core jobs in the queue. These will only run in -dev. Let us know how you get on. I'll put some single-core jobs up as well, so people not in -dev can get some work too.

Hmm, there is a little problem with that -- The workflow manager is holding that batch in acquired status while the 2- and 4-core batches run and probably won't start it running until those queues start running dry, which could take some time!

---

Yes, we're working on it, but it takes time. Currently we have some two-core and some 4-core jobs in the queue. These will only run in -dev. Let us know how you get on. I'll put some single-core jobs up as well, so people not in -dev can get some work too.

Hmm, there is a little problem with that -- The workflow manager is holding that batch in acquired status while the 2- and 4-core batches run and probably won't start it running until those queues start running dry, which could take some time!

We still don't have any 1-core jobs available for CMS@Home "production". Federica is going to kill her 2-core workflow, so then hopefully the workflow-manager will notice that there aren't many jobs in the queue, and will move my workflow into the "running" state.

---

Yes, we're working on it, but it takes time. Currently we have some two-core and some 4-core jobs in the queue. These will only run in -dev. Let us know how you get on. I'll put some single-core jobs up as well, so people not in -dev can get some work too.

Hmm, there is a little problem with that -- The workflow manager is holding that batch in acquired status while the 2- and 4-core batches run and probably won't start it running until those queues start running dry, which could take some time!

We still don't have any 1-core jobs available for CMS@Home "production". Federica is going to kill her 2-core workflow, so then hopefully the workflow-manager will notice that there aren't many jobs in the queue, and will move my workflow into the "running" state.

OK, aborting the rather large two-core workflow has allowed my latest single-core batch to get its foot in the door. Currently we are running a 4-core w/f, accessible only to users of CMS@Home-dev who have set their MaxCPUsPerTask to >=4, and a single-core w/f that will run on "production" CMS@Home VMs, and at reduced efficiency (for N>1) for -dev Volunteers running N-core VMs
I'll try to keep the mix tuned over the holidays. We plan to allow multicore on production tasks after the break, I'll let you know when you can start experimenting with the number of cores as that happens. I think we'll concentrate mainly on 4-core, as that's where CMS seems to be focussing its efforts.

---

It needs to be clarified whether

1. a workflow batch at the backend must be configured to run on n cores before any work is sent out

2. a task on a volunteer VM can forward it's own #cores to the CMS app and CMS uses this #cores.
Like:
2-core VM -> 2-core CMS
4-core VM -> 4-core CMS


Sending out something like fix n-core CMS tasks to a VM not running n cores makes no sense.

Tja, the permutations become exponentially weird. Currently
o "Normal" single core jobs are available. These will run on "standard" LHC@Home machines, which cannot specify multicore VMs, and on LHC@Home-dev machines which specify NCPUs >=1 -- only using one core in the VM of course.
o A workflow specifying 4-core jobs is also available. These can run on LHC@Home-dev machines specifying NCPUs >=4.

I don't think we can specify workflows to "run on however many cores are available". The relevant parameter in the .json config file is "Multicore", which as far as I know takes an integer parameter at submission time.

---

So do the multicore work units actually get 4 times the work done using four cores?
I'd check myself but when I asked to join -dev I was told I wasn't required.

So do the multicore work units actually get 4 times the work done using four cores?
I'd check myself but when I asked to join -dev I was told I wasn't required.

Sorry about that, the decision was made by LHC@Home management.
Yes, since our jobs are mostly "embarrassingly parallel" the trend is to run multithreaded jobs so that each core runs over events individually. There are memory savings because of all the shared resources which only need to be loaded once.

---

Yes, I am *clearly* a trouble maker after all. Utterly incorrigible. ;)

Thanks for that, I'm looking for ward to seeing how these run in production.

Yes, I am *clearly* a trouble maker after all. Utterly incorrigible. ;)

I'll take your word for it...

Thanks for that, I'm looking for ward to seeing how these run in production.

You can see my poor underpowered machine's tasks here.
I think Laurence still has some holidays in his pocket, so we may not turn on multicore in production until next week.

---

Yes, I am *clearly* a trouble maker after all. Utterly incorrigible. ;)

I'll take your word for it...

Thanks for that, I'm looking for ward to seeing how these run in production.

You can see my poor underpowered machine's tasks here.
I think Laurence still has some holidays in his pocket, so we may not turn on multicore in production until next week.

Well ... I could if I had an account on the -dev project. Thanks anyway.

the queue ran dry :-(

Any word on release to production yet?

Any word on release to production yet?

Yes, in fact. We activated multi-core in production this afternoon, and there are some 4-core jobs queued up ready to run. You can try setting your preferences for your favourite CMS@Home locale to using 4-core VMs, and see if you pick up a task. There will still be single-core jobs hanging around, so the current choices are just single- or quad-core tasks. Note that we haven't tuned the 4-core jobs yet, so you might run into bandwidth, memory or time-out problems.

---

If the #cores must be configured at batch creation time, then please make a decision.

Either keep only the singlecore app
or drop the singlecore app and send out a multicore with a fix #cores that is in sync with the backend.

Do not mix batches having different core settings as this would break BOINC's work fetch, runtime estimation, credit system ...

I have one of the four core processes running now but there is a bug. It is using four cores but claims to be using five cores, so one core isn't being used by BOINC at all. I have five set as my maximum in my preferences, which I can change but this should be fixed.

Thank you.

If the #cores must be configured at batch creation time, then please make a decision.

Either keep only the singlecore app
or drop the singlecore app and send out a multicore with a fix #cores that is in sync with the backend.

Do not mix batches having different core settings as this would break BOINC's work fetch, runtime estimation, credit system ...

A fair point, I'll keep it in mind.

---

I'm wondering if we got the multi-core config right on the production CMS@Home. Of the machines I'm running in a locale where I've selected 4-CPU tasks, all are running just a single-core VM. A machine running a 4-core locale at CMS@Home-dev has started a 4-core VM, though.

---

When you look at your computers tasks on the website, are they vbox64 or vbox64_mt_mcore_cms? Ben's computer was showing one off each outstanding / in progress

vbox64 and vbox64_mt_mcore_cms should be identical when the number of threads/cpus for vbox64_mt_mcore_cms is equal to 1. We can probably deprecate vbox64 if there are no issues with vbox64_mt_mcore_cms

When you look at your computers tasks on the website, are they vbox64 or vbox64_mt_mcore_cms? Ben's computer was showing one off each outstanding / in progress

Just vbox64, I'm afraid.

---