LHC@home

Typical config entries

/etc/cvmfs/default.local

CVMFS_REPOSITORIES="atlas.cern.ch,atlas-condb.cern.ch,grid.cern.ch,cernvm-prod.cern.ch"

[...]

It should be checked (by the project team) if CVMFS_SERVER_URL lists at least 4 servers. Then it's very unlikely that all of them fail at the same moment.

Client side issues could be:
- wrong firewall settings, e.g. closed ports or filtered destinations
- slow DNS resolving
- high load on the router (not the same as high bandwidth usage!) that causes timeouts

Yeah, thank you. Otherwise I can write a bash script that parses stderr.txt and automatically aborts the concerning task when three "Probing /cvmfs/*... Failed!" are raised (and those three lines must be consecutive).

#!/bin/bash

boinc_path="/home/luis/Applicazioni/boinc"
lhc_project_url="https://lhcathome.cern.ch/lhcathome/"
atlas_app_name="ATLAS"
boinccmd="./boinccmd"

function isAtlasTask()
{
	init_data="$boinc_path/slots/$1/init_data.xml"
	if [ -e "$init_data" ]; then
		app_name=$(sed -n 's|[^<]*<app_name>\([^<]*\)</app_name>[^<]*|\1\n|gp' $init_data)
		if [[ "$app_name" == "$atlas_app_name" ]]; then
			return 1
		else
			return 0
		fi
	fi
	return 0
}

slot_dirs=( $(ls "$boinc_path/slots"))
ndirs=${#slot_dirs[@]}
for (( i = 0; i < ndirs; i++ )) do
	isAtlasTask $i
	if [ $? -eq 1 ]; then
		stderr="$boinc_path/slots/$i/stderr.txt"
		c=0
		while IFS= read -r line; do
			if [[ "$line" == *"Probing /cvmfs/"*"... Failed!" ]]; then
				c=$((c+1))
			fi
		done < "$stderr"
		echo "$c probing fails found in $stderr"
		if [ $c -ge 3 ]; then
			boinc_task_state="$boinc_path/slots/$i/boinc_task_state.xml"
			task_name=$(sed -n 's|[^<]*<result_name>\([^<]*\)</result_name>[^<]*|\1\n|gp' $boinc_task_state)
			cd $boinc_path && $boinccmd --task $lhc_project_url $task_name suspend #abort
			echo "$task_name suspended!" #aborted!"
		fi
	fi
done

watch -n 900 /your_script_path/AtlasProbingFailedCheck.sh

- If the probe fails, the probe logs the messages like you saw but then continues (I changed this not to fail the job because the probe failure can be temporary)

I think what it happening in your case is that there is a problem with CVMFS which causes the copy of the bootstrap script to hang forever. I can put a timeout around this to avoid blocking the task forever but I'll need to make changes in the VM and make a new app version. I will look into it next week since I am away at a conference this week.

2019-10-31 14:38:31 (2419): Guest Log: Probing /cvmfs/atlas.cern.ch... Failed!
2019-10-31 14:38:31 (2419): Guest Log: Probing /cvmfs/atlas-condb.cern.ch... Failed!
2019-10-31 14:38:31 (2419): Guest Log: Probing /cvmfs/grid.cern.ch... Failed!

2019-10-31 03:26:08 (30814): Guest Log: Probing /cvmfs/atlas.cern.ch... Failed!
2019-10-31 03:26:08 (30814): Guest Log: Probing /cvmfs/atlas-condb.cern.ch... Failed!
2019-10-31 03:26:11 (30814): Guest Log: Probing /cvmfs/grid.cern.ch... OK

2019-10-31 17:06:19 (1960): Guest Log: Probing /cvmfs/atlas.cern.ch... Failed!
2019-10-31 17:06:19 (1960): Guest Log: Probing /cvmfs/atlas-condb.cern.ch... Failed!
2019-10-31 17:06:23 (1960): Guest Log: Probing /cvmfs/grid.cern.ch... OK

2019-10-31 13:57:56 (12291): Guest Log: Probing /cvmfs/atlas-condb.cern.ch... OK
2019-10-31 13:57:59 (12291): Guest Log: Probing /cvmfs/grid.cern.ch... OK

The benchmark results seem to be valid for that CPU.
[...]
OTOH BOINC's credit calculation includes some components to identify outliers or cheats.
As a result the credit reward for a single task should not be treated as stable.
It will need at least a week without any setup changes to get stable values.

[quote]I suppose, you are not satisfied with the credit ??

hihi, with the value 97,40 I wouldn't be satiesfied either :-)
even my old old old AMD Turion Dual-Core ZM-80 (contained in a notebook) produces more than 200 points within about same processing time.

The measured floating point speed of 0.87 billion ops/sec is that correct?

Run CPU benchmarks from BOINC Manager's Tools menu and system not used for the rest.

freq    ( flo/  int)
 800MHz ( 452/ 3048)
1000MHz ( 565/ 3831)
1200MHz ( 679/ 4649)
1400MHz ( 792/ 5413)
1600MH  ( 905/ 6188)
1800MHz (1017/ 6942)
2000MHz (1131/ 7727)
2200MHz (1243/ 8484)

Just reduce the number of CPUs on your web preferences and the rsc_memory_bound is reduced accordingly. I have set 4 CPUs on web site and Boinc reserves 3750 MB memory for each Theory task. I have set 730 MB and 1 CPU core with app_config and that is what the app is actually using.

Anyway I have set 8-thread VMs and it's working fine compared to 1 year ago (post 36607).

From BOINC Manager it results:
CPU time = 51.1h
elapsed time = 7.5h
working set size = 6.59GB

Average CPU used: 51.1 / 7.5 = 6.8
I hope BOINC credits would not drop when I run 1 task.

they use the same amount of RAM as before, but due to this (probably unintended) change in the parameters, BOINC thinks the VM needs much more RAM and therefore does not let start more than just a few VMs at a time.

Could someone get this problem of the too high RAM allocation solved?