LHC@home

I just saw the notice on Sixtrack News about lack of work. Ok. I'd like to talk about the lack of work on LHCb and the vbox projects.

Lack of work on those projects has a greater impact then lack of work on Sixtrack. This is because the vbox projects hold a BOINC slot while waiting for work, not only is the vbox project doing nothing, it's preventing BOINC from running a different project. It also holds a slot while doing the very low value tasks of uploading and downloading, which BOINC could do nicely without holding a slot.

I just looked at my BOINC processes. I am running 6 cpu slots, all occupied by an LHC vbox task, but only 2 using CPU. 3 active is probably more common, but still not very efficient.

I understand why you use vbox and Linux, and I have no complaint with that. But I wish the project were set up to work in a more typical BOINC fashion:
1. BOINC downloads input files.
2. Spin up a VM and process the input files.
3. Exit the VM.
4. BOINC uploads the results.

I'm donating my machine resources on the assumption that they are being used productively. Holding slots while doing nothing or almost nothing isn't making good use of my resources.

++PLS

ATLAS already behaves like you request it (1..4).

Theory's intermediate results are very small.
As long as you don't get a bad Sherpa job it should use nearly 100% of your CPU.

LHCb:
Very annoying!
I can't remember any sustainable efficiency improvement nor any comment from the LHCb team although a couple of volunteers asked for it again and again.

ATLAS already behaves like you request it (1..4).

Theory's intermediate results are very small.
As long as you don't get a bad Sherpa job it should use nearly 100% of your CPU.

Not really.,

I've had multi-cpu tasks for ATLAS and Theory running..From looking at the CPU and elapsed time, and checking on CPU used, both go long periods using zero CPU. I think both are holding resources while waiting for tasks to become available. Actually, holding 4 or 6 slots while doing nothing but waiting.

My whole point was that this is not an efficient way to work. Let BOINC download the files, And don't spin up a 6 CPU VM unless at least 6 tasks are downloaded and waiting. And when those tasks are done, leave politely.

++PLS

You're right. They do hold resources while waiting for sub-tasks to be made available. It's not efficient but that's not going to change. Single core tasks are said to be considerably more efficient than 6 core tasks.

, And don't spin up a 6 CPU VM unless at least 6 tasks are downloaded and waiting.

But AIUI it's the stuff within the VM that requests the actual jobs/sub-tasks and downloads the payload.

This issue is why the advice that single-CPU VMs are more efficient is repeated often on these boards.

(In my experience single-CPU VMs also avoid a bunch of spurious heartbeat errors, but that's another story)

---