LHC@home

I have some running at -dev but that site needs to be poked with a stick since it is just blank pages for everything so we can't see what is going on.

web and scheduler: enable plan classes for BUDA

If you make a variant of a BUDA app for a plan class
(e.g. NVIDIA GPU with CUDA)
this ensures that jobs submitted to that variant are sent
only to capable hosts,
and that the host usage and projected FLOPS are set correctly.

On the web side, we add a <plan_class> element to workunit.xml_doc.
This gets sent to the scheduler.

On the scheduler this required some reorganization.
As the scheduler scans jobs, it finds and caches
a BEST_APP_VERSION for each app.
This contains a HOST_USAGE.

In the case of BUDA, the host usage depends on the workunit,
not the app version.
We might scan several BUDA jobs
they'll all use the same APP_VERSION,
but they could have different plan classes
and therefore different HOST_USAGE.

The integrated luminosity of the proton run, which denotes the number of collisions recorded, reached almost double the best performance achieved in previous runs, with124 inverse femtobarns for both the @atlasexperiment and the @cmsexperiment. Later, during the 17-day lead-ion run, an integrated luminosity of 1.98 inverse nanobarns was delivered to the @alice_experiment, an equivalent amount to last year.

Particles are set to return to the accelerator chain at the beginning of March 2025 and to the LHC at the beginning of April.

the singular reason to switch Windows machines from VBox to Docker, which is unnecessary anyway, would be to shut you up.

You consider that a "vast" difference. That pretty much settles the validity of the rest of your complaint. Enjoy your whinge.

Not even "ultra-vast majority".

You know all those VBox apps are running Linux inside the VMs, right.

Personally, I run the Native apps.

Yes, you said ALL.

Not true.

Simply not true for LHC@home. See statistics page.

Virtualbox runs just fine. I see no need for Docker.

Don't need no stincking Docker on Linux. Boinc runs just fine as is!

- New philosophy: always query the presence of software (WSL distros, Docker)
even if client config doesn't allow its use.
Send the config info to scheduler, and enforce it there.
- New philosophy: allow running jobs in any WSL distro
except those disallowed in the config

- Add plan class support for WSL and Docker app versions

- client: query the libc version of WSL distros.
The plan class entry for a WSL app version
can specify a min libc version.

- wsl_wrapper: add --min_libc_version cmdline arg
(should match plan class spec)