LHC@home

On my laptop there is this WU: https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=187809749 : 42,648.50 84,649.43 197.45

On.my Ryzen 9 3950 there are these:

https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=187820769 : 30,082.22 58,198.01 139.27
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=187820739 : 33,903.55 65,691.93 1,569.61
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=187828931 : 34,723.24 66,261.05 5,643.76
https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=187825310 : 32,956.64 62,686.52 10,081.02

That's ok.
You will find no identical Cpu-Time or run-Time for Atlas-Tasks.

And everyone loves a 9hr 2-core task that gives them over 10,000 Credits

This "creditnew" nonsense, as it's called, has got to go. These numbers are meaningless since a comparison between any two of them is apples-to-oranges by design -- unless you are comparing those from two tasks run on the same exact machine under the same exact conditions.

It is dismaying that the administrators of LHC@Home are in any way comfortable with this state of affairs, as most other BOINC projects have categorically avoided creating such a problem for themselves.

At any rate, as a CPU project, it would be too small a fraction of my overall BOINC credit to make a mathematically significant impact to my numbers anyway, so I can't complain that much. The only value credits have here, for my part, _is_ their usefulness in comparing the relative effectiveness of different hardware, but with the way LHC@Home is configured, the only thing that would make these stats useful is mathematically impossible to do.

When it comes to this project, I just crunch, ignore the statistics, and hope the results are useful. At least we can take comfort in the certain knowledge that the science is real and priceless. And also that it gives me an excuse to exercise and maintain a working Squid/CVMFS/Singularity stack, which is pretty darn cool ngl.

Sagittarius Lupus wrote:

...exercise and maintain a working Squid/CVMFS/Singularity stack.

Just to mention it.
This is from one of your ATLAS logs:

[2023-05-12 23:31:28] 2.10.1.0 53510 232 45828 118935 1 46 3898658 4096000 0 130560 0 208626 99.982 138921 4864 http://s1bnl-cvmfs.openhtc.io/cvmfs/atlas.cern.ch http://127.0.0.1:3128 1

CVMFS accepts a proxy at 127.0.0.1.


This is from one of your CMS logs:

2023-05-12 03:26:12 (1829563): Guest Log: [INFO] Excerpt from "cvmfs_config stat": VERSION HOST PROXY
2023-05-12 03:26:12 (1829563): Guest Log: [INFO] 2.7.2.0 http://s1fnal-cvmfs.openhtc.io:8080 DIRECT
2023-05-12 03:26:12 (1829563): Guest Log: [INFO] Environment HTTP proxy: not set

CMS runs inside a VM which has it's own loop device 127.0.0.1.
The way you configure the proxy IP tells CMS to use a proxy inside the VM.
Since the VM doesn't have a proxy it uses DIRECT.


Solution

Tell BOINC to use the proxy's local network IP (or DNS name) instead of the loopback IP, e.g. 198.51.100.37.
That IP will be forwarded to the processes inside the VM.