Currently, I've only run Amicable in MT mode. The Einstein tasks are defined as GPU-only, but I've allocated them a full CPU core via app_config.xml because of the OpenCL overhead. I run NumberFields as a simple, lightweight, CPU-only project.

Have you seen #5257? Several bits of fine-tuning in there.

Currently, I've only run Amicable in MT mode. The Einstein tasks are defined as GPU-only, but I've allocated them a full CPU core via app_config.xml because of the OpenCL overhead. I run NumberFields as a simple, lightweight, CPU-only project.

Have you seen #5257? Several bits of fine-tuning in there.

"Just looked the Einstein ones that crashed were all gravity wave 4CPU + GPU The Gamma Ray which says in Manager, 1CPU+1NvidiaGPU is now at 18% so clearly not subject to whatever made the others crash about 1 minute in.

Just looked the Einstein ones that crashed were all gravity wave 4CPU + GPU

That's odd - I didn't think they had such a beast. I've only ever run tasks designed as 1 GPU plus fractional CPU, although I've usually controlled them with app_config, often to run two per GPU.

The latest Gravity Wave GPU tasks have a high GPU memory demand, so I can't run two per card - although I can run 1 GW plus 1 Gamma-ray. They seem to be running down the supply of GW tasks at the moment, so I'm only getting resends: I expect that's in preparation to start clean with a new batch of data.

Just started testing again. 30% of cores available. One 4 core Amicable running 1 1CPU Einstein and 1 1CPU+!GPU Einstein. This is actlually 37.5% Even if as is I believe the case with some GPU tasks that the load on the CPU is minimal the other 5 cores in use would constitute 31.25% of available cores. So clearly an over commit.

Now to increase core count and see what happens.

I increased %CPUs to 55. (Not something I normally do as on the type of tasks I typically run there is no gain from using more than 50%) None of the three Einstein tasks waiting to run have started. Still just the four core Amicable Numbers task and two single core Einstein one of which also used the GPU

Now I know it does not only affect CPDN work waiting to run.

Not sure are the only non VB Atlas tasks the ones that need cvfms? I am currently looking at the cmake output log to try and determine where cmake fell over.

Edit: I needn't have bothered for all the sense it made. Not like Make where it tells you what was missing!

Can't help, I'm afraid - I just installed whatever was needed from the CERN cerncvm repository - can't find the installation guide right now.

computezrmle (a few posts ago) is an expert in this field.

Can't help, I'm afraid - I just installed whatever was needed from the CERN cerncvm repository - can't find the installation guide right now.

computezrmle (a few posts ago) is an expert in this field.

I tried following the guide for Debian doing it from scratch.

No worries. If I get any more tasks from CPDN before the East Asia ones arrive, I can always run other stuff in VB where it can just do its own thing. I would like to chase the issue down and work out what the problem is but more out of academic interest than necessity.

Edit: Just found the .deb files on the CERN site.

Just started testing again. 30% of cores available. ...
... increased %CPUs to 55. ...

Didn't recently test BOINC's behaviour regarding the core percentage setting.

At least far in the past it worked in intervals.
On Dave's 16 core computer the interval is 100/16=6.25
Hence, each setting 50 <= x < 56.25 results in the same number of cores that will be used.

=> It shouldn't make a difference whether it is set to 50% or 55% but you may see a difference if you set 57%.

Yes, it's always 'next integer below'.

Edit: Just found the .deb files on the CERN site.

cvmfs_2.10.1~1+ubuntu22.04_amd64.deb
cvmfs-fuse3_2.10.1~1+ubuntu22.04_amd64.deb

The first one fails with

The following packages have unmet dependencies.
cvmfs: Depends:cvmfs-config-default but it is not installable or cvmfs-config but it is not installable

I probably have time to sort this before Atlas tasks become available again.

The following packages have unmet dependencies.
cvmfs: Depends:cvmfs-config-default but it is not installable or cvmfs-config but it is not installable

You also need this package:
http://ecsft.cern.ch/dist/cvmfs/cvmfs-config/cvmfs-config-default_latest_all.deb

First you need to do after installation is to run (once!):
[sudo] cvmfs_config setup

Never directly modify the options in any *.conf file below /etc/cvmfs
Instead create a corresponding *.local file and write the modification to that file.

I probably have time to sort this before Atlas tasks become available again.

That's why I suggested CMS from LHC@home dev since this has mt tasks available and does only need VirtualBox.

That's why I suggested CMS from LHC@home dev since this has mt tasks available and does only need VirtualBox.

Thanks, I was planning on testing with non VB MT tasks first. Will have a think about this.

And thanks for the link to the needed .deb. I now have my machine set up for the non-VB tasks.

Now downloading a 7 core task from LHC. Might pause it in order to be awake to see what happens.

Edit: It is a VB one.

Same happens as with Amicable numbers. 7 core task started, 2 Einstein tasks stopped. Increased number of available cores to 8, Neither of the Einstein tasks started, LHC started to download a task for 8 cores.

Now downloading a 7 core task from LHC. Might pause it in order to be awake to see what happens.

Edit: It is a VB one.

Pausing tasks from LHC@home can be tricky.
CMS: If they pause for more than 2h they loose connection to WMAgent and cancel their subtask; depending on the runtime the either finish or try to get another subtask
ATLAS native: always restarts from scratch
Theory native: requires cgroups v1 and a special preparation; does not work on cgroups v2

LHC started to download a task for 8 cores

ATLAS has a server side max core limit of 8 for Vbox and 12 for native tasks.

Pausing tasks from LHC@home can be tricky.

Just pausing before it started which won't cause problems. Even increasing core count to 100% Einstein task didn't restart. with 8 core task from LHC running. So I have my answer now that it isn't just MT tasks from AN causing the issue.

I wonder why I didn't see it - what's the difference?

I wouldn't mind looking through a complete cycle of cpu_sched_debug, if you could put one where I can see it? Compare it with the one I posted on GitHub for DA, on the different issue I saw.

I wonder why I didn't see it - what's the difference?

I wouldn't mind looking through a complete cycle of cpu_sched_debug, if you could put one where I can see it? Compare it with the one I posted on GitHub for DA, on the different issue I saw.

Will wait for current tasks to finish, then set it up to record from starting the single core tasks. - About a couple of hours.

That would be great - I'll keep an eye on things when I get back from lunch.