Development for LHC@home

I have a couple of machines running CMS-dev today for Ivan's challenge, but neither of them is in the room where I'm typing this - one is on the floor above, the other on the floor below.

BOINC's own Manager can connect to both remote machines (one at a time), and manage everything to do with standard BOINC jobs. But neither 'Show graphics' nor 'VM console' is available, except when the Manager on the local machine is used. Perhaps that's one the CERN developers and the BOINC developers could think about together.

For Windows users, there are at least a couple of enhanced management tools with network management capability for BOINC: BoincView (very ancient, and no longer maintained, but it still works), and BoincTasks, which is still under active support. Both of these tools calculate and display a value for "CPU efficiency" (a concept which was dropped from BOINC itself several years ago), and I can tell that both VMs have CMS jobs - well, something - running, because CPU efficiency is currently in the high 90s on both machines. Periodically, I notice that one or other of them has 'gone yellow' (BoincView's colour coding for low efficiency jobs), which I presume implies that CMS has finished one internal job and may (or may not) be starting another.

Which leads me to another thought. Surely some helpful person could write a watchdog script which periodically tested CPU efficiency for CMS jobs, and if it fell below threshhold, use boinccmd to tweak <max_ncpus_pct> to allow an additional task to use the idle core, and stop it again when CMS was active.

Thoughts?

You can use an RDP client on a remote computer to connect to the cruncher - once you know what port it's on. I know of no easy way to find this out, so I use VNC to find out the RD port and then keep an eye on the cruncher's "top" screen with "Remote Desktop Connection" (on Windows) or something similar. Shame this doesn't work for the web server, so you're limited to the various consoles - no logs, although the odd behaviour of the cmsRun log updates has led me astray so maybe that's no bad thing at the moment.

Edit. At the moment I've got a beautiful updating display of what looks like cmsRun log using alt-F5. Better than top but doesn't always work.

On BoincView, if you look in it's program folder, there's a file boincview.ini in which is a SlowProgress item. Changing this alters the colour change threshold but the changes don't stick... not on mine anyway which sometimes stays green between jobs, too.

You can use an RDP client on a remote computer to connect to the cruncher - once you know what port it's on. I know of no easy way to find this out, ...

You find it at:

\\ComputerName\Drive$\BOINC_Data\slots

Open the Slot where CMS is running and there you will find it in: vbox_remote_desktop.xml

Which leads me to another thought. Surely some helpful person could write a watchdog script which periodically tested CPU efficiency for CMS jobs, and if it fell below threshhold, use boinccmd to tweak <max_ncpus_pct> to allow an additional task to use the idle core, and stop it again when CMS was active.

Thoughts?

Perhaps this could be embedded in BOINc itself. Some communication between VM wrapper/VM and BOINC deamon to tell it when VM goes in low CPU consumption state (downloading data, boots or anything but running CPU-intensive job). At such moments BOINC could schedule additional task from other CPU-intensive project if available. Cause for this apps such inactive periods of time measured by minutes or even more (when internet connection drop VM will sit idle, but BOINC task will continue to occupy CPU core) scale it's worth to implement.

P.S. To make this post I presented with logon page (cause writing from new to this project PC) but then instead of get editor window I got 404 not found message. Going through "Your account"(to ensure I logged on)->Message boards and so on avoid that "404". This unrelated to thread topic but smth this forum admin could think of.

You can use an RDP client on a remote computer to connect to the cruncher - once you know what port it's on. I know of no easy way to find this out, ...

You find it at:

\\ComputerName\Drive$\BOINC_Data\slots

Open the Slot where CMS is running and there you will find it in: vbox_remote_desktop.xml

Thanks, Yeti, but I wanted to do this automatically, so that I could just click on something and it would be there. Starting with only the project name I couldn't work out how to find the slot(s) remotely so it didn't get me anywhere.

On BoincView, if you look in it's program folder, there's a file boincview.ini in which is a SlowProgress item. Changing this alters the colour change threshold but the changes don't stick... not on mine anyway which sometimes stays green between jobs, too.

You can also configure both the colour used and the trigger threshhold from the BoincView GUI itself - toolbox button, tooltip "Open program preferences" (or simply F11). Colour is in the 'Look' section, threshhold in 'Tasks'. That seems to stick. (I'm using v1.4.2 - I think that was the final non-beta)

I'll have a poke around the other suggestions for remote viewing this afternoon, and maybe write up a BOINC enhancement request. And maybe I'll ask Efmer how the gets the efficiency value for BoincTasks, and see if I can work out a way to script it (the rest should be easy). As Raistmer says, we wouldn't want fine-grained control - it wouldn't be the end of the earth if BOINC ran over-committed or under-committed for five minutes, or even for an hour.

Boinctasks is an awesome enhancement to BOINC. I run 30 odd systems scattered about the place on windows, linux and anderoid and have complete control of each client through a single computer. Saves tons of time, swapping displays etc and is so simple to see what a system is doing, if it has crashed etc. etc.

Me too, BOINCTasks is really great.

Which leads me to another thought. Surely some helpful person could write a watchdog script which periodically tested CPU efficiency for CMS jobs, and if it fell below threshhold, use boinccmd to tweak <max_ncpus_pct> to allow an additional task to use the idle core, and stop it again when CMS was active.

Thoughts?

For Windows you could start with the command:

wmic cpu get loadpercentage

Depending on the outcome and on your needs use a higher value of ncpus in cc_config.xml in combination with an alternate of global_prefs_override.xml for processors to use.

For Windows you could start with the command:

wmic cpu get loadpercentage

Sadly, I'm not getting very far with that.

wmic cpu get loadpercentage
LoadPercentage
93

doesn't tell me much about how many of the four or eight cores on the machine are running flat out - and how many of them are running CMS-dev

wmic process where name="vboxheadless.exe" get UserModeTime
UserModeTime
312002
156001
3996277617

is more promising - I could call it twice, with a timed pause between, and work out the diff. But I'm sure there must be a better way. Anyone?

Depending on the outcome and on your needs use a higher value of ncpus in cc_config.xml in combination with an alternate of global_prefs_override.xml for processors to use.

Yes - I was thinking along those lines too. boinccmd can't control the percentage directly, but we could have

global_prefs_override_CMSruns.xml
global_prefs_override_CMSstop.xml

and copy the right one to plain global_prefs_override.xml and re-read it.

BoincView...
You can also configure both the colour used and the trigger threshhold from the BoincView GUI itself - toolbox button, tooltip "Open program preferences" (or simply F11). Colour is in the 'Look' section, threshhold in 'Tasks'. That seems to stick. (I'm using v1.4.2 - I think that was the final non-beta)

Forgot that, thanks Richard.