Message boards :
Number crunching :
Work unit hold a slot but doing nothing
Message board moderation
Author | Message |
---|---|
Send message Joined: 22 Oct 07 Posts: 27 Credit: 808,821 RAC: 0 |
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 |
Send message Joined: 15 Jun 08 Posts: 2411 Credit: 226,099,688 RAC: 127,426 |
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. |
Send message Joined: 22 Oct 07 Posts: 27 Credit: 808,821 RAC: 0 |
ATLAS already behaves like you request it (1..4). 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 |
Send message Joined: 13 Apr 18 Posts: 443 Credit: 8,438,885 RAC: 0 |
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. |
Send message Joined: 13 Jul 05 Posts: 167 Credit: 14,945,019 RAC: 623 |
, 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) |
©2024 CERN