LHC@home

I have a host (Win10-64, 4GB RAM, Q6600, BOINC 7.14.2, VBox 5.2.8) that I'm pretty sure used to be able to run at least 2 (if not 3 or 4) Theory tasks at a time in the days before the multi-threaded app. It seems now that it will successfully and consistently complete a Theory task using the MT app when running only one task at a time that is allotted one core (leaving the other three cores mostly idle).

Although it has completed one task at a time using both two and four cores, they ran for only a short period of time (less than 30 minutes). Otherwise, all tasks with (1) more that one core allotted or (2) multiple tasks with a single core allotted, resulted in a computation error with an EXIT_ABORTED_BY_CLIENT code and a line in the stderr output "VM Heartbeat file specified, but missing heartbeat."

Also, although the one task/one core tasks complete, the VM log is full of the "Giving up catch-up attempt" messages.

Is there anything I can do to improve the performance or is this host simply underpowered for today's VM work? It's disappointing that I can't fully utilize it at LHC when there are no SixTrack tasks... :-(

Is there anything I can do to improve the performance or is this host simply underpowered for today's VM work? It's disappointing that I can't fully utilize it at LHC when there are no SixTrack tasks... :-(

Hi Mark, I suppose you are running also other projects on that host like World Community Grid.

Vboxwrapper is running on a lower priority than VirtualBox's VBoxSVC.exe.
Therefore on busy systems the communications between those 2 processes is sometimes too slow for the wrapper.
You could lower VBoxSVC.exe priority to 'below normal' before a Vbox-task has started and raise the priority of vboxwrapper to 'below normal' too or even 'normal'.

Vboxwrapper is running on a lower priority than VirtualBox's VBoxSVC.exe.
Therefore on busy systems the communications between those 2 processes is sometimes too slow for the wrapper.
You could lower VBoxSVC.exe priority to 'below normal' before a Vbox-task has started and raise the priority of vboxwrapper to 'below normal' too or even 'normal'.

Thanks for the feedback, Lammert (I was hoping I might hear from you!).

While trying to figure out what -- if anything -- I can do to get more out of this host on LHC, I haven't been running any other projects. On this Windows machine, I'm not sure how identify and change the vboxwrapper and vboxsvc process priorities and I'm not sure it's worth the trouble to do that every time a new task starts (if that's what you mean). I think I'll probably just move this host to another project. I've got 18 other cores running Theory and Atlas tasks without any problem.

On this Windows machine, I'm not sure how identify and change the vboxwrapper and vboxsvc process priorities and I'm not sure it's worth the trouble to do that every time a new task starts ...

I think you know BoincTasks. The program to manage several BOINC-hosts. From the same developer you may use http://efmer.eu/download/boinc/priority/Priority_1_2.zip for setting priorities automatically.
Be sure it's started when your system boots. One disadvantage: all added exe's will get the same priority. In our case that would be 'below normal', but above 'low' or 'idle'.
After a boot or BOINC (re)start, be sure VBoxSVC.exe is running e.g. by opening VirtualBox Manager, before starting or resuming a BOINC-VM (LHC-task)

A copy of the Priority-program could set the wrapper to 'normal', when the above solution would not help enough

On Windows 10 if you run task manager from start menu.or the taxk bar chevron, right click, you can access process details and modify priority from there easily enough.
You may know this now- but others reading may like to know.
I have trouble running VBox Boincs, but that's perceived to be due to having only 4gb Ram, which only runs Cosmology 3Cores - & then with care.
Rosetta and LHC struggle a lot more and the former no longer tries to send VBox work- for obvious reasons, due to failures previously.
Looking around for solutions there seems to be a lot of adverse comment on the low level of user support afforded on VBox usage.
There have been a coupkle of VB updates since your earlier post, but even then some have preferred to stick with older versions- if working well.