Development for LHC@home

I get a bunch of condor_mips and condor_kflops (benchmarkings?) and now some cmsRun jobs running for about an hour each.

It took ~40mins for cmsRun to first appear and about 70mins before it seemed to settle down to running continuously at ~80%CPU and 30%MEM.

Hopefully the startup sequence can be made a lot faster than this.

Thanks for the feedback. It is good to see that it is working for most. We can always optimize later once we know where the issues are.

It is good to see that it is working for most.

Well, so far it's had an easy run here. The PC nearly to itself and it has been running (cmsRun now shows nearly two hours) undisturbed. It has yet to live with vLHC and a couple of others. Also, tomorrow morning a cron job will turn the PC off. The CMS task will have to survive all this.

The first cmsRun "job" seems to have finished after ~174min and another has started. After only a few minutes it was up to 80% in contrast to the first job which took a long time to get going. Now to see how well task switching works.

This suggests that the first time it was downloading files into the CVMFS cache. Proving a new image that has these files baked in should solve the problem.

I have created a new app version (46.17) that upgrades the vboxwrapper to version 26169.

I have created a new app version (46.17) that upgrades the vboxwrapper to version 26169.

The bad news is, this still doesn't run on my Win7 box with VirtualBox 4.3.30. :-(

The good news is -- it does run under VirtualBox 5.0! :-)
Still have no idea what the problem was, tho'but...

Usual problem, though, it's stalled after startup.

getProxystderr:
$ cat getProxystderr

curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Error opening input file cert.p12
cert.p12: No such file or directory
Error opening input file cert.p12
cert.p12: No such file or directory
chmod: cannot access `userkey.pem': No such file or directory
chmod: cannot access `usercert.pem': No such file or directory
get_proxy.sh: line 27: grid-proxy-init: command not found
get_proxy.sh: line 32: grid-proxy-info: command not found

...and -- now it's run further.

---

So CMS-dev needs Vbox 5 but Atlas won't run with that version yet ?

I have created a new app version (46.17) that upgrades the vboxwrapper to version 26169.

I had v26169 already running with VBox5.0, but will reset the project to get the stock versions of the files, when current cmsRun has finished.

Proving a new image that has these files baked in should solve the problem.

Did you also changed the VM?

Wrapper 26169 seems to be working fine with VBox 4.3.26 here.

Okay thanks, my 46.16 jobs are due to start finishing in about an hours time, will watch and see how 46.17 jobs get on without changing anything.

So CMS-dev needs Vbox 5 but Atlas won't run with that version yet ?

No, my machine wouldn't run with later versions of Vbox 4 (it ran OK with 4.3.12); others had no such problem.

---

We don't need Vbox 5 but the new wrapper should support its use.

No not yet, I want to clean a few things up first. Once CVMFS has updated you should see lots of new log files in the graphics. Also console 2 should show a clean ps output that should help you to see when cmsRun is running.

Working fine for me.
So far done two cmsrun jobs at around 50 mins each.

Three Win 7 boxes have completed their 46.16 jobs and started 46.17, all seem to be running okay and after 40 minutes CMSrun is running though not at full power yet.

Out of interest, the credit scoring seems all over the place. A slower box got a credit of 467 for 66,672 seconds of cpu time, two similar faster boxes got 872 points for 61,537 cpu time and 933 points for 52,396 cpu time. All 3 took the usual elapsed time (for Windows) of just over 24 hours.

The credit system is probably normalizing for the power of the different machines.

I had v26169 already running with VBox5.0, but will reset the project to get the stock versions of the files, when current cmsRun has finished.

I resetted the project. Got vboxwrapper_26169 from the project, yesterday's CMS*.xml and the CMS-vdi of March.
This time the 1st cmsRun started 8 minutes after the boot.
Alt+F2 now shows some PID's, runtimes and CMD's (processnames).
Alt+F5 no output (yet?) and in the logs only a boot.log

Two linux boxes have now started 46.17 jobs, still no problems.

They took just under 24 hours (as usual) to complete the 46.16 jobs and scored 854 for 67,849 cpu and 924 for 73,717 cpu seconds.

The low scoring windows box is much older/slower but the other 4 are quite similar though they are running other different things at the same time. Before you did these recent changes it used to be that the older box and my slow laptop got better scores than all the faster boxes !