LHC@home

Tasks do nothing and end with error after 15-20 minutes.

which is typical for "no sub-tasks available"

Yes, sorry about that. We seem to have a problem with queued jobs: there are two queues for each batch submitted, "queued" and "pending", both of which I believe have a 2,000-job limit. When I submit a batch, recently of 10,000 jobs each, jobs are created if necessary up to that number, to fill the "queued" queue; contemporaneously, jobs are moved from "queued" to "pending" until it also is full. In recent weeks, apparently since there was an interruption to the DNS service at CERN, there seems to have been a disruption in taking jobs from the "pending" queue and allocating them to worker machines -- only a small fraction get sent.
What happened last night was that the current batch's "queued" queue drained, and job allocation from the "pending" jobs dropped off (there are currently 1200 pending and 13 running; in the previous batch 232 are still pending and 36 running!). At CMS IT's suggestion, I've been playing around with batch priority but that's had no perceptible effect. I'll have to just make sure that I submit new batches before the "queued" queue drains -- there's a new batch on its way so things should pick up again soon.
I'll contact CERN again and suggest they restart the Condor scheduler.

...Remember ATLAS was not initially developed for BOINC. It was developed for a vast network of many thousands of non-BOINC hosts on CERN's own non-BOINC distributed computing network. BOINC is just an after thought, a mere add on attached to their DC network with bits of glue and twine. BOINC delivers up only a few hundreds of hosts that together return a miniscule amount of work compared to CERN's own DC network. While they certainly appreciate our contributions there is a limit on how much effort they should invest in keeping less capable BOINC hosts happy.

... Is it this statement that indicates success?
2018-04-11 01:37:31 (7056): Guest Log: Successfully finished the ATLAS job!

It depends on the perspective.
"Guest Log: Successfully finished the ATLAS job!" indicates a successful end of the BOINC task and your host will most likely get credits.

From the science perspective a file like "HITS.*" contains the results and should be included in the upload.
This name normally appears in the directory listing that is included in the stderr.txt and can be checked there.

2018-04-11 01:37:31 (7056): Guest Log: HITS.13684178._016629.pool.root.1 srm://srm.ndgf.org:8443;autodir=no;spacetoken=ATLASDATADISK/srm/managerv2?SFN=/atlas/disk/atlasdatadisk/rucio/mc16_13TeV/f3/ae/HITS.13684178._016629.pool.root.1:checksumtype=adler32:checksumvalue=b9f476d

again I had an ATLAS task with runtime of about 10 minutes:
https://lhcathome.cern.ch/lhcathome/result.php?resultid=186994334

Very strange.
Even your valid tasks show incomplete logs:
https://lhcathome.cern.ch/lhcathome/result.php?resultid=186915983
https://lhcathome.cern.ch/lhcathome/result.php?resultid=186900508
https://lhcathome.cern.ch/lhcathome/result.php?resultid=186900791

You may consider to stop your BOINC client, clean the VirtualBox environment and do a project reset before you start a fresh task.

We're in a transitional stage at the moment, unfortunately with Easter looming, but the good bit of news I can impart is that as of a day or two ago we are writing merged result files into the T2_CH_CERN storage -- which means they are now available world-wide to anyone in CMS who wants to use them. *NOW* the challenge is to get workflows that suit our capabilities and limitations and produce results that end up in papers we can all point to with pride!

have you removed the max concurrent running tasks cap or is it still in place?

[quote]
You could fix it for your machines with a small app_config.xml in the Project-Directory of LHCATHOME

<app_config>
 <app>
 <name>ATLAS</name>
 <max_concurrent>12</max_concurrent>
 </app>
 </app_config>

This idea to let 1000 Collisions running with Linux-native App is NOT against Windows, sorry.

There are more Computer with running Linux-App to do this heavy work.
David had a statistic for one week shown in this thread:
https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4396&postid=33036#33036

The current ATLAS tasks process 100 events, but as an experiment we have sent some tasks with 1000 events. We would like to see if it's possible to run tasks like these on ATLAS@Home because this is the same number of events each task processes on the ATLAS grid. It would make things a lot easier if the same tasks could run on ATLAS@Home as on the rest of the ATLAS grid.

These tasks will run 10 times longer than the other tasks and will generate an output file 10 times as large (500MB), so this may be an issue for those of you with low upload bandwidth. The advantage is that the initial download of 200MB is the same. Obviously using more cores will be better for these tasks, so they finish in a reasonable time.

To know if you are running one of these tasks and that it's not a regular "longrunner" you can check the stderr.txt in the slots directory - if it shows "Starting ATLAS job. (PandaID=xxx taskID: taskID=10959636)" then you got one. The regular tasks have taskID=10947180.

Please let us know your opinion in general about the length and data in/out requirements of ATLAS tasks. They are usually much shorter than the other vbox LHC projects - is this a good thing or would you prefer more consistency among the projects?

This is the beginning of this thread from David!

What's about 1.000 events running in nativeApp for Linux only?
There is not so a overhead and is running very stable. In the preferences is a flag useful therefore.
Is there a second chance......