LHC@home

I got a bunch of new Atlas tasks last night and they all are 2050 events. So on a 4 thread VM they will take about 30 hours each!

---

Now I am getting new tasks with 3800 events. Why the change? These cannot be processed in time!

---

Have reduced to one Task, since you wrote this.
Got one Atlas, but with 400 Events, as always before.

Have reduced to one Task, since you wrote this.
Got one Atlas, but with 400 Events, as always before.

Where does one find the number of events a task will process?

Have reduced to one Task, since you wrote this.
Got one Atlas, but with 400 Events, as always before.

Where does one find the number of events a task will process?

This way works even if the task hasn't started yet:
- locate Boinc's data directory for LHC tasks. For Windows it is a hidden folder, usually at c:\ProgramData\BOINC\projects\lhcathome.cern.ch_lhcathome
- find the task name you are interested in in Boinc manager (like yCqKDmbjhO5nsSi4apGgGQJmABFKDmABFKDm4ySLDmn2HKDmr3rD5n_0)
- in the above mentioned Boinc LHC directory locate the file yCqKDmbjhO5nsSi4apGgGQJmABFKDmABFKDm4ySLDmn2HKDmr3rD5n_input.tar.gz
- copy it to an other directory (like tmp)
- open it with a file packer manager (for example 7-zip manager)
- there is a yCqKDmbjhO5nsSi4apGgGQJmABFKDmABFKDm4ySLDmn2HKDmr3rD5n_input.tar inside the gz-file, double click it in the 7-zip manager
- there are many folders (long path) inside the tar-file, go to the last folder of the path. There you see 4 files.
- view the content of the file pandaJobData.out
- seach for a string maxEvents
- after that string you see something like %3D2050+. The 2050 is the number of events for that task.

I hope this helps.

---

- view the content of the file pandaJobData.out
- seach for a string maxEvents
- after that string you see something like %3D2050+. The 2050 is the number of events for that task.

I hope this helps.

It does. I too am seeing 3800 events.
I also see a field saying this: skipEvents%3D2800
and another one saying: firstEvent%3D2982801

Any idea what these mean?

BTW, what I am seeing in the Boinc data directory is already the input.tar.gz file (eg. Pp9KDmy1uO5n9Rq4apoT9bVoABFKDmABFKDmlqFKDmNQFKDmS9AmEm_input.tar.gz)
This is Linux, so maybe things are a bit different from what they are in Windows.

Have reduced to one Task, since you wrote this.
Got one Atlas, but with 400 Events, as always before.

Where does one find the number of events a task will process?

For a running task use the VM Console from BOINC Manager.
You should have installed VirtualBox Extention Pack for that (the same version as VirtualBox Manager): https://www.virtualbox.org/wiki/Downloads
When you see the Console you may use ALT-F1 (system console - startup), ALT-F2 (Event Progress Monitoring) and ALT-F3 (Linux command 'top')
The 400 events tasks don't have a nice output all the time, but the 1850 and 1950 events tasks have.

Uploading a 1.12GB HITS-file from a 1950 events-task: LHC@home GQZKDmAlCP5nsSi4apGgGQJmABFKDmABFKDm4ySLDmFhIKDmAjaRan_0_r1821662343_ATLAS_hits 1172589,63 K

Uploading a 1.12GB HITS-file from a 1950 events-task: LHC@home GQZKDmAlCP5nsSi4apGgGQJmABFKDmABFKDm4ySLDmFhIKDmAjaRan_0_r1821662343_ATLAS_hits 1172589,63 K

It's not always that easy. What a waste of CPU power:

</stderr_txt>
<message>
upload failure: <file_xfer_error>
<file_name>s6KLDmcWvO5nsSi4apGgGQJmABFKDmABFKDm4ySLDmeIIKDmKgRVom_0_r1124613539_ATLAS_hits</file_name>
<error_code>-131 (file size too big)</error_code>
</file_xfer_error>
</message>
]]>

It seems that the 3800 event files are the ones that are failing with that error. The tasks have produced HITS files over 2 GB in size shown by your stderr.

---

It seems that the 3800 event files are the ones that are failing with that error. The tasks have produced HITS files over 2 GB in size shown by your stderr.

Next of them:

https://lhcathome.cern.ch/lhcathome/result.php?resultid=410882063

</stderr_txt>
<message>
upload failure: <file_xfer_error>
<file_name>dmoNDmiavO5nsSi4apGgGQJmABFKDmABFKDm4ySLDmuIIKDm8rjr3n_0_r1349242912_ATLAS_hits</file_name>
<error_code>-131 (file size too big)</error_code>
</file_xfer_error>
</message>
]]>

I will abort the rest of these "long runners"
Another waste of 17h x 4 cores 😥️

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
These long runners are really a problem and the project should avoid to send them to volunteers.
The problem is not only that they run that long, but they produce big upload files exceeding the
max_nbytes project setting of 2000000000 bytes (1.8626 GB) for the HITS-result file and BOINC will not upload that file.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
These long runners are really a problem and the project should avoid to send them to volunteers.
The problem is not only that they run that long, but they produce big upload files exceeding the
max_nbytes project setting of 2000000000 bytes (1.8626 GB) for the HITS-result file and BOINC will not upload that file.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Long runners are o.k. for me.
But I would expect the possibility to upload the result.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
These long runners are really a problem and the project should avoid to send them to volunteers.
The problem is not only that they run that long, but they produce big upload files exceeding the
max_nbytes project setting of 2000000000 bytes (1.8626 GB) for the HITS-result file and BOINC will not upload that file.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Long runners are o.k. for me.
But I would expect the possibility to upload the result.

Not all volunteers are crunching LHC only and not all volunteers are running their machine(s) 24/7.
ATLAS and CMS have the bad habit, that they need an internet connection all the time.

I aborted all the 3800 event tasks and downloaded a few new ones. The new ones were 400 event tasks.

---

Uploading a 1.12GB HITS-file from a 1950 events-task: LHC@home GQZKDmAlCP5nsSi4apGgGQJmABFKDmABFKDm4ySLDmFhIKDmAjaRan_0_r1821662343_ATLAS_hits 1172589,63 K

For the moment seeing also 10 Tasks with 1950 Events and an uploadfile of 1.12 GByte.
So, this double Events of 1.950 (3.900) are TOO BIG and have more than 2 GByte upload.
We have to watch this Tasks and delete them.
Maybe, they are for Cern inside.

Since this morning I only get 400 events tasks.

Get four new Atlas-Tasks, but
because of the longrunners (only one task in use),
have to wait a few days to see how many events they have.
Hoping 400 as yours.
We have in prefs a venue to activate longrunners.
Why coming they with those 400 Event Tasks?

... When you see the Console you may use ALT-F1 (system console - startup), ALT-F2 (Event Progress Monitoring) and ALT-F3 (Linux command 'top')
The 400 events tasks don't have a nice output all the time, but the 1850 and 1950 events tasks have.

What's the explanation for this behaviour?

... When you see the Console you may use ALT-F1 (system console - startup), ALT-F2 (Event Progress Monitoring) and ALT-F3 (Linux command 'top')
The 400 events tasks don't have a nice output all the time, but the 1850 and 1950 events tasks have.

What's the explanation for this behaviour?

I don't have a deep insight in the VM structure. In the past the 'workers' each had their own directory/folder for logging.
Then it was changed with the garbage as a result. It seems that other scientists creating tasks to the BOINC pool are using the old structure.
At least for us volunteers the progress was much better to follow in the past and accidentally every now and then.