LHC@home

Per Crystal Pellet:

"I think BOINC's feeder gets confused when there is a massive amount of SixTrack workunits in the queue as we've seen before.
Even when requesting SixTrack's, you often get the message 'No tasks available'."

https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4513&postid=33587#33587

and

"The issue seems to be related to the combined presence of short SixTrack tasks and a huge backlog of tasks for SixTrack. "

I was thinking you could bundle 20 to 100 Sixtrack in it's own VBox d/l, thus averaging the short runs with longer runs and reduce the number of Sixtrack WU's in queue by 20-100 times. You already have the VM's developed and it could solve all these feeder issues.
It's what I already do with Sixtrack on one machine.

I have a very different perspective. SixTrack is a very active sub project, because it's system requirements are generally low and downloads are small. You'll find systems on Sixtrack that no other LHC project could support.

Not requiring VBOX is a major part of that. Vbox installs are troublesome still. New users are often turned away from LHC because they don't want to deal with the checklist -- and they shouldn't have to. ATLAS native App is no solution because it adds several layers of difficulty. Also, the native app does very little for users even if they are on linux. Major complaints remain download size and system requirements. My system, at least, received the same size downloads in addition to CVMFS traffic. If LHC can use a cache that's great, but doesn't help users with limited internet traffic. And I didn't see improvements in system usage or stability (pausing tasks specifically).

I fear users will be excluded if changes are made that profit a small minority.

I have a very different perspective. SixTrack is a very active sub project, because it's system requirements are generally low and downloads are small. You'll find systems on Sixtrack that no other LHC project could support.

Not requiring VBOX is a major part of that. Vbox installs are troublesome still. New users are often turned away from LHC because they don't want to deal with the checklist -- and they shouldn't have to. ATLAS native App is no solution because it adds several layers of difficulty. Also, the native app does very little for users even if they are on linux. Major complaints remain download size and system requirements. My system, at least, received the same size downloads in addition to CVMFS traffic. If LHC can use a cache that's great, but doesn't help users with limited internet traffic. And I didn't see improvements in system usage or stability (pausing tasks specifically).

I fear users will be excluded if changes are made that profit a small minority.

It's all good points.The Sixtrack VM doesn't need to eliminate the native Sixtrack. It would just be available to those who desire it and would likely be always available while the feeder has trouble with the regular Sixtrack. It would also be another lower requirement option since it would have similar 630MB RAM usage as Theory.

Consider my suggestion as an option, not a replacement, and as a method to keep Sixtrack flowing during these rough patches.

I don't want to exclude low RAM or low core count users. That was me last year with one of my laptops having only 2GB RAM and my main machine was a 1090t with only 8GB RAM.

As mentioned, you can get this message from the BOINC client when the shared memory buffer of the BOINC scheduler runs out of tasks between feeder queries. This occurs from time to time on our server, notably when many clients pull tasks at the same time and there are short tasks that finish after a short time. (This can be the case for Sixtrack simulations with parameters leading to unstable particles.)

Sadly yesterday and today the problem is much worse than usual as the response-time of our database is degraded and BOINC has problems pulling out tasks from the DB. At times BOINC clients will not be able to fetch any task from LHC@home, not even for the VM applications.

We are trying to understand the cause of this with our database experts, and hope that tasks should flow normally again soon. Thanks for your understanding and happy crunching!