LHC@home

The app on LHC-dev has VERY low ETAs as in a couple min vs reality of possibly days. Possibility as in the tasks ran from 30 min to 4 days on the same PC. They also run to 100% quickly then sit there for days. Hopefully the low ETA and running to 100% is fixed as it doesn't play nice with how the client operates.

As some have seen, be wary of admins dumping work so no one gets credit for completed work.

365 units cancelled by server.
Oof!

In my case, 6 running XTrack tasks were cancelled by server, with a total processing time of 103840 seconds (more than 28 hours).
Time/energy wasted, or useful for something?

Yeah 18 running tasks cancelled each with over 6 hours run time
All my other tasks can't be validated so I will get nothing for this lot of work

Conan

---

Magic Quantum Mechanic wrote:

https://lhcathomedev.cern.ch/lhcathome-dev/results.php?hostid=5072&offset=0&show_names=0&state=5&appid=16
https://lhcathomedev.cern.ch/lhcathome-dev/results.php?hostid=4786&offset=0&show_names=0&state=5&appid=16
https://lhcathomedev.cern.ch/lhcathome-dev/results.php?hostid=5326&offset=20&show_names=0&state=5&appid=16

enormous runtimes, but no credit points at all :-(

I think we can call this "a joke".

The XTrack application is currently labeled as beta, so you may encounter issues until it is officially released. Running the beta is still valuable, it helps validate and strengthen the app. Some problems may involve credit, and in certain cases, credit might not be granted even if tasks complete successfully. If you require stability and guaranteed credit, we recommend not running beta applications.

Exactly!

What is not clear is since you have (the luxury to have) a whole development and test project (AFAIK one of the rare, or last, project to have this) where only a portion of crunchers agree to go and calculate test applications, for all projects, when you need it, therefore this project here is considered by the community of crunchers as a *production* project.

So now you decide to deploy this app here, still you label it "beta" but you never do this for any other app (since you have LHCdev), this app was actually created on LHCdev and is still running there, so we can only consider that it is now declared as stable and worth being put here (regardless its name). Even I was doubting "is it really the same app ?" and this was confirmed to me here.

So you should also considering how *frustrating* it can be for us volunteer donor participants that so many tasks being suddenly canceled without any warning, even running tasks. There is nothing worse for a cruncher that wasted CPU cycles.

And don't look down on us as you are doing, in particular computezrmle.

There is no stable/production app version without a previous debugging version...
Therefore, I consider it useful to continue running beta versions, at my on risk

... you label it "beta" but you never do this for any other app ...

That's wrong.
Most of the apps were first marked beta, e.g. ATLAS native, Theory native ...

There is nothing worse for a cruncher that wasted CPU cycles.

It was your explicit decision to allow beta apps.
So, don't blame others for that.

As for cancelling the batch:
It was the right decision to avoid many other crunchers "waste" anything.

It was the right decision to avoid many other crunchers "waste" anything.

Probably. With a fair warning would have been better.

Thanks for Frederik's constructive and *humble* explanations.

So, if I want to run Xtrack (beta) on a windows computer what options should I have set?
Currently I have the following set:
Use CPU and Run test applications, SixTrack, CMS Simulation, Theory Simulation, ATLAS Simulation, XTrack

Which leaves these two not selected::
If no work for selected applications is available, accept work from other applications?, and Run native if available? (Not recommended for Windows)

Out of habit I run a very small cache, and shut down every night - do either of these get in the way?

---

SixTrack will (most likely) never return since it will be replaced by Xtrack.
It is still in the list to keep the credits people got in the past.
So, it doesn't matter whether you keep it activated or not.

To get tasks from any app marked as beta (https://lhcathome.cern.ch/lhcathome/apps.php) you must allow beta apps.
Otherwise you will only get tasks from apps not marked as beta.

To get tasks for apps marked as "(native_*)" your client must run under Linux and "Run native if available?" must be enabled.
If this is enabled for a Windows client it will get no tasks, even if vbox tasks are available.

shut down every night

According to the comments (so far) Xtrack shouldn't have problems with this (but it needs to be verified).
The more complex apps often have problems with
- lots of restarts
- throttling them down extremely, e.g. due to virtualbox timing issues
- network sockets (connections to project servers) that time out during shutdown, e.g. CMS

Hi all,
As always, thanks for crunching our jobs.
Your contribution is highly valued.

Cheers,
Frederik

Could increasing the deadline be a solution?

Even if an application appears solid in the development project, the production project is a different environment, running at scale. Labeling the application as beta reflects that difference and is intended to set expectations. It also allows volunteers who want to focus solely on crunching, without engaging in the development process, to do so.

We very much value those who do choose to test beta applications and provide feedback, even knowing they may not receive credit for failures. All feedback we receive is appreciated and acknowledged by the whole community.

Fresh batch was just released!
Picked up 8 tasks on an i7-1165G7 (Win11) and after 10 minutes they are all past 99.5% and apparent progress has slowed to 0.003%/second. So far behavior seems similar to earlier batches.

---

Have finished a few of these new ones. All finished tasks are valid and did get credit but they contain this on stderr.txt:

<core_client_version>8.0.2</core_client_version>
<![CDATA[
<stderr_txt>
strftime() failed called boinc_finish(0)

</stderr_txt>
]]>

---

Have finished a few of these new ones. All finished tasks are valid and did get credit but they contain this on stderr.txt:

<core_client_version>8.0.2</core_client_version>
<![CDATA[
<stderr_txt>
strftime() failed called boinc_finish(0)

</stderr_txt>
]]>

First two finished after 2 hours (on Linux), got credited and also produced a successful stderr:

<core_client_version>7.24.1</core_client_version>
<![CDATA[
<stderr_txt>
2025-09-26 15:27:27 (19450): called boinc_finish(0)

</stderr_txt>
]]>

---

I've the same issue, but only on my Windows results "strftime() failed called boinc_finish(0)" (XTrack v0.41 windows_x86_64)
for Linux I get a valid result "2025-09-26 13:30:28 (57641): called boinc_finish(0)" (XTrack v0.41 x86_64-pc-linux-gnu)

---

Matthias