1) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7160)
Posted 24 Mar 2021 by zombie67 [MM]
Post:
Uploads are taking 2-3 hours each.
2) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7153)
Posted 23 Mar 2021 by zombie67 [MM]
Post:
Wow. Lots of download errors again. So many, that I am now getting:

lhcathome-dev 3/23/2021 12:02:00 PM This computer has finished a daily quota of 1 tasks
3) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7151)
Posted 23 Mar 2021 by zombie67 [MM]
Post:
Am I the only one not getting work since about 10 hours ago?

Edit: Of course, as soon as I posted that, I started getting work again.
4) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7147)
Posted 23 Mar 2021 by zombie67 [MM]
Post:
FWIW, all my machines have dried up. Server status page says 300+ tasks available, but nothing will download.
5) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7146)
Posted 22 Mar 2021 by zombie67 [MM]
Post:
Thanks for the info. Even running 8x 4-core tasks, they are finishing in about 7 hours. So no issue WRT time limit. I guess I will just pick the middle and run 4x 8-core tasks.
6) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7144)
Posted 22 Mar 2021 by zombie67 [MM]
Post:
Let's say you have a 32 core machine. Is it better to run a single task using 32 cores? Or 4 tasks using 8 cores each? Or 8 tasks using 4 cores each? I have tried all three configurations and the credits per hour work out to be roughly the same. As far as I can tell, there is no advantage to me regardless of configuration.

So my question is, does the project have a preference?
7) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7108)
Posted 19 Mar 2021 by zombie67 [MM]
Post:
Yes, I ran the native stuff years ago. It's just been so long that I forgot all about it.
8) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7106)
Posted 19 Mar 2021 by zombie67 [MM]
Post:
...No cvmfs_config command found...

This is an ATLAS native test.
ATLAS native requires a local CVMFS client to be installed and correctly configured.

See the message board threads over at the -prod pages.


I assumed "native" just meant meant that a VM was no longer needed (no vbox required). It's been so long since I ran the native thing, I forgot all about all the additional manual steps required.
9) Message boards : ATLAS Application : ATLAS long simulation 1.01 (Message 7103)
Posted 19 Mar 2021 by zombie67 [MM]
Post:
I am getting nothing but errors:

https://lhcathomedev.cern.ch/lhcathome-dev/result.php?resultid=2958101

<core_client_version>7.16.6</core_client_version>
<![CDATA[
<message>
process exited with code 195 (0xc3, -61)</message>
<stderr_txt>
05:25:13 (131525): wrapper (7.7.26015): starting
05:25:13 (131525): wrapper: running run_atlas (--nthreads 32)
[2021-03-19 05:25:13] Arguments: --nthreads 32
[2021-03-19 05:25:13] Threads: 32
[2021-03-19 05:25:13] Checking for CVMFS
[2021-03-19 05:25:13] No cvmfs_config command found, will try listing directly
[2021-03-19 05:25:13] ls: cannot access '/cvmfs/atlas.cern.ch/repo/sw': No such file or directory
[2021-03-19 05:25:13] Failed to list /cvmfs/atlas.cern.ch/repo/sw
05:35:14 (131525): run_atlas exited; CPU time 0.005612
05:35:14 (131525): app exit status: 0x1
05:35:14 (131525): called boinc_finish(195)

</stderr_txt>
]]>
10) Message boards : News : New native Linux ATLAS application (Message 4776)
Posted 4 Mar 2017 by zombie67 [MM]
Post:
Same here. On Ubuntu 14.04.5

$ ldd /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libNet.so
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libNet.so: /lib/x86_64-linux-gnu/libcrypto.so.10: version `libcrypto.so.10' not found (required by /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libNet.so)
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libNet.so: /lib/x86_64-linux-gnu/libssl.so.10: version `libssl.so.10' not found (required by /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libNet.so)
linux-vdso.so.1 => (0x00007ffd85dbb000)
libRIO.so => /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libRIO.so (0x00007fe736a90000)
libMathCore.so => /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libMathCore.so (0x00007fe736657000)
libcrypto.so.10 => /lib/x86_64-linux-gnu/libcrypto.so.10 (0x00007fe73627b000)
libssl.so.10 => /lib/x86_64-linux-gnu/libssl.so.10 (0x00007fe73601c000)
libCore.so => /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libCore.so (0x00007fe735646000)
libCint.so => /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libCint.so (0x00007fe734a49000)
libstdc++.so.6 => /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasSite/gcc-links/x86_64-slc6-gcc47-opt/lib64/libstdc++.so.6 (0x00007fe734742000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe73452c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe734167000)
libThread.so => /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libThread.so (0x00007fe733f13000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe733d0f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe733a09000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe7337f0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe73730c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe7335d2000)

$ ls -l /lib/x86_64-linux-gnu/libcrypto.so.10 /lib/x86_64-linux-gnu/libssl.so.10
lrwxrwxrwx 1 root root 40 Mar 3 18:42 /lib/x86_64-linux-gnu/libcrypto.so.10 -> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
lrwxrwxrwx 1 root root 15 Mar 3 16:58 /lib/x86_64-linux-gnu/libssl.so.10 -> libssl.so.1.0.0

I also added /lib/x86_64-linux-gnu/ to the environment variable LD_LIBRARY_PATH to no avail.
$ echo $LD_LIBRARY_PATH | awk '{ split($0,t,":"); for (i in t) print t[i] }'
/lib/x86_64-linux-gnu
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/tdaq-common/tdaq-common-01-28-00/installed/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasAnalysis/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/Java/JDK/1.6.0/amd64/jre/lib/amd64
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasTrigger/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/Java/JDK/1.6.0/amd64/jre/lib/amd64/server
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasReconstruction/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasEvent/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasConditions/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasCore/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/DetCommon/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/Java/JDK/1.6.0/amd64/jre/lib/amd64/native_threads
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/GAUDI/v25r3p1/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/Java/JDK/1.6.0/amd64/jre/lib/amd64/xawt
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/LCGCMT/LCGCMT_67b/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/coin3d/3.1.3p2/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/MCGenerators_lcgcmt67b/hydjet/1.6/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/soqt/1.5.0_qt4.8.4_coin3d3.1.3p2/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasSite/gcc-links/x86_64-slc6-gcc47-opt/lib64
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/dqm-common/dqm-common-00-26-02/installed/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/Python/2.7.3/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasOffline/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/lcg/external/qwt/6.0.1_qt4.8.4/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/external/yampl/1.0/x86_64-slc6-gcc47-opt/lib
/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasSimulation/19.2.4/InstallArea/x86_64-slc6-gcc47-opt/lib

$ Sim_tf.py
PyJobTransforms.<module> 2017-03-03 18:49:10,239 INFO logging set in /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/share/bin/Sim_tf.py
PyJobTransforms.main 2017-03-03 18:49:11,009 INFO This is /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/share/bin/Sim_tf.py
PyJobTransforms.transform.parseCmdLineArgs 2017-03-03 18:49:11,018 INFO Transform command line was: '/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/share/bin/Sim_tf.py'
PyJobTransforms.transform.execute 2017-03-03 18:49:11,018 INFO Starting to resolve execution graph
PyJobTransforms.transform.execute 2017-03-03 18:49:11,021 INFO Execution graph resolved
PyJobTransforms.transform.execute 2017-03-03 18:49:11,021 INFO Starting to trace execution path
PyJobTransforms.transform.execute 2017-03-03 18:49:11,021 INFO Execution path found with 1 step(s): EVNTtoHITS
PyJobTransforms.transform.validateInFiles 2017-03-03 18:49:11,022 INFO Validating input files
PyJobTransforms.trfValidation.performStandardFileValidation 2017-03-03 18:49:11,022 INFO Starting legacy (serial) file validation
PyJobTransforms.trfValidation.performStandardFileValidation 2017-03-03 18:49:11,022 INFO Stopping legacy (serial) file validation
PyJobTransforms.trfExe._detectAthenaMP 2017-03-03 18:49:11,022 INFO No AthenaMP options found - assuming normal athena run
PyJobTransforms.trfJobOptions.writeRunArgs 2017-03-03 18:49:11,022 INFO Writing runArgs to file "runargs.EVNTtoHITS.py"
PyJobTransforms.trfJobOptions.writeRunArgs 2017-03-03 18:49:11,022 INFO Successfully wrote runargs file runargs.EVNTtoHITS.py
PyJobTransforms.trfExe.preExecute 2017-03-03 18:49:11,023 INFO Asetup report: AtlasBaseDir=/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4
AtlasProject=AtlasProduction
AtlasVersion=19.2.4.9
AtlasPatch=AtlasProduction
AtlasPatchVersion=19.2.4.9
CMTCONFIG=x86_64-slc6-gcc47-opt
No readable patch area found
PyJobTransforms.trfUtils.releaseIsOlderThan 2017-03-03 18:49:11,023 INFO Detected release major 19, minor 2 (.4.9) from environment
PyJobTransforms.trfEnv.probeIMFSettings 2017-03-03 18:49:11,023 INFO Enabling IMF by default for release
PyJobTransforms.trfEnv.probeTcmallocSettings 2017-03-03 18:49:11,024 INFO Skipping inclusion of tcmalloc
PyJobTransforms.trfExe._prepAthenaCommandLine 2017-03-03 18:49:11,024 INFO Setting athena preloadlibs to: /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libintlc.so.5:/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libimf.so
PyJobTransforms.trfExe._prepAthenaCommandLine 2017-03-03 18:49:11,024 INFO Skipping test for "--drop-and-reload" in this executor
PyJobTransforms.trfExe._prepAthenaCommandLine 2017-03-03 18:49:11,024 INFO Updated script arguments with topoptions: ['athena.py', '--preloadlib=/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libintlc.so.5:/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libimf.so', 'runargs.EVNTtoHITS.py', 'SimuJobTransforms/skeleton.EVGENtoHIT_ISF.py']
PyJobTransforms.trfExe.preExecute 2017-03-03 18:49:11,024 INFO Will execute script as ['athena.py', '--preloadlib=/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libintlc.so.5:/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libimf.so', 'runargs.EVNTtoHITS.py', 'SimuJobTransforms/skeleton.EVGENtoHIT_ISF.py']
PyJobTransforms.trfExe.preExecute 2017-03-03 18:49:11,024 INFO Interactive environment detected (stdio or stdout is a tty) - enabling command echoing to stdout
PyJobTransforms.trfExe.preExecute 2017-03-03 18:49:11,025 INFO Now writing wrapper for substep executor EVNTtoHITS
PyJobTransforms.trfExe._writeAthenaWrapper 2017-03-03 18:49:11,025 INFO Valgrind not engaged
PyJobTransforms.trfExe.preExecute 2017-03-03 18:49:11,025 INFO Athena will be executed in a subshell via ['./runwrapper.EVNTtoHITS.sh']
PyJobTransforms.trfExe.execute 2017-03-03 18:49:11,025 INFO Starting execution of EVNTtoHITS (['./runwrapper.EVNTtoHITS.sh'])
EVNTtoHITS 18:49:11 Fri Mar 3 18:49:11 CST 2017
EVNTtoHITS 18:49:11 Preloading tcmalloc_minimal.so
EVNTtoHITS 18:49:11 Preloading /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libintlc.so.5:/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/sw/IntelSoftware/linux/x86_64/xe2013/composer_xe_2013.3.163/compiler/lib/intel64/libimf.so
EVNTtoHITS 18:49:11 Py:Athena INFO including file "AthenaCommon/Preparation.py"
EVNTtoHITS 18:49:11 Py:Athena INFO using release [AtlasProduction-19.2.4.9] [x86_64-slc6-gcc47-opt] [19.2.X.Y-VAL-Prod/rel_3] -- built on [2015-08-12 02:01]
EVNTtoHITS 18:49:11 Py:Athena INFO including file "AthenaCommon/Bootstrap.py"
EVNTtoHITS 18:49:11 Py:Athena INFO including file "AthenaCommon/Atlas.UnixStandardJob.py"
EVNTtoHITS 18:49:11 Traceback (most recent call last):
EVNTtoHITS 18:49:11 File "/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasCore/19.2.4/InstallArea/jobOptions/AthenaCommon/Preparation.py", line 86, in <module>
EVNTtoHITS 18:49:11 import cppyy
EVNTtoHITS 18:49:11 File "/cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/atlas/offline/external/root-snapshot/atlas-5.34.13p1/x86_64-slc6-gcc47-opt/lib/cppyy.py", line 52, in <module>
EVNTtoHITS 18:49:11 import libPyROOT as _backend
EVNTtoHITS 18:49:11 ImportError: /lib/x86_64-linux-gnu/libcrypto.so.10: version `libcrypto.so.10' not found (required by /cvmfs/atlas.cern.ch/repo/sw/software/x86_64-slc6-gcc47-opt/19.2.4/AtlasProduction/19.2.4.9/InstallArea/x86_64-slc6-gcc47-opt/lib/libNet.so), ROOT version or setup problem?
PyJobTransforms.trfExe.execute 2017-03-03 18:49:11,475 INFO EVNTtoHITS executor returns 1
11) Message boards : News : New native Linux ATLAS application (Message 4716)
Posted 24 Feb 2017 by zombie67 [MM]
Post:
Although I recommend the use of a proxy you may try it direct.


Insert the following line in your /etc/cvmfs/default.local
CVMFS_HTTP_PROXY=DIRECT

then execute "cvmfs_config reload".

This is documented for Mac OS X but it may work on Linux also.


It worked! Thanks!
$ cvmfs_config probe
Probing /cvmfs/atlas.cern.ch... OK
Probing /cvmfs/atlas-condb.cern.ch... OK
Probing /cvmfs/grid.cern.ch... OK
12) Message boards : News : New native Linux ATLAS application (Message 4713)
Posted 24 Feb 2017 by zombie67 [MM]
Post:
I am having problems

$ cvmfs_config probe
Probing /cvmfs/atlas.cern.ch... Failed!
Probing /cvmfs/atlas-condb.cern.ch... Failed!
Probing /cvmfs/grid.cern.ch... Failed!
$ ping atlas.cern.ch
ping: unknown host atlas.cern.ch
$ ping google.com
PING google.com (172.217.6.46) 56(84) bytes of data.
64 bytes from sfo03s08-in-f14.1e100.net (172.217.6.46): icmp_seq=1 ttl=53 time=19.2 ms


I can't reach the cern servers. Maybe it wants me to set a proxy? But I don't use a proxy.
13) Message boards : Theory Application : New Muti-core version V1.9 (Message 3677)
Posted 14 Jul 2016 by zombie67 [MM]
Post:
How will the BOINC client be able to know to run only one of these tasks, which will use all CPU threads, and no other CPU tasks of any kind from any other project? Or even tasks from other applications on the same project?

Also, Assuming a single task using 4 CPU threads within the VM, how will BOINC know to credit 4x threads of CPU time?

Here is the thing: Without using a VM, BOINC can already do all this natively. Several projects already use this method. Are we trying to re-create something already available, just so that it can be in a VM?
14) Message boards : ALICE Application : The ALICE Application (Message 3646)
Posted 12 Jul 2016 by zombie67 [MM]
Post:
Congratulations to zombie67 who ran the first successful test job for ALICE!



Weee! However, I am also getting a lot of errors. They all seem to fail at 7 minutes.
15) Message boards : News : Project Configuration Update 2 (Message 3469)
Posted 22 May 2016 by zombie67 [MM]
Post:
Yes, that's to avoid overloading hosts without resources to run several tasks at once. You can edit the file to allow more, and then reload config files to bring it into effect.


By resources, are you talking only about memory? Or also CPU threads?

What are the maximum resources any give task could require? That will help us decide the maximum number of tasks to run at a time.

Thanks!
16) Message boards : News : VBox wrapper problems (Message 122)
Posted 20 Mar 2015 by zombie67 [MM]
Post:
Although this doesn't address any other macs attached. A better solution is to remove the mac app until you are ready to have people run it again.


I'm only running two Macs but I agree with Z67 that removing the app is the cleaner solution. I only burned through 150 WUs before I saw this.

S.


If this also effects linux, then that app should also be depreciated.
17) Message boards : News : VBox wrapper problems (Message 119)
Posted 20 Mar 2015 by zombie67 [MM]
Post:
They are macs. Could that have something to do with the short run time?

Yes, there are known bugs with the Mac and Linux 26155 vboxwrapper which we are currently debugging. This causes rapid task termination and of course eats these tasks so please hold off for now, OK?


I have turned them off for now. Let us know when you want to test the fixes.

Edit: Although this doesn't address any other macs attached. A better solution is to remove the mac app until you are ready to have people run it again.
18) Message boards : News : VBox wrapper problems (Message 116)
Posted 20 Mar 2015 by zombie67 [MM]
Post:
They are macs. Could that have something to do with the short run time?
19) Message boards : News : VBox wrapper problems (Message 113)
Posted 20 Mar 2015 by zombie67 [MM]
Post:
I just checked. The tasks I crunched were only across a handful of machines. The number of machines is not the problem, it's the extremely short run time. Any of us could have burned through them. I just had the luck of the BOINC back-off algorithm.
20) Message boards : Number crunching : A std::exception was thrown. (Message 87)
Posted 17 Mar 2015 by zombie67 [MM]
Post:
A number of my guests running under Linux seem to be stalling with a Fatal exception. Are we maybe taxing the incoming server a bit much? Or is this actually somewhat normal processing? :)

Exception Message:
A std::exception was thrown.
Can not get data (Additional Information: [frontier.c:799]: No more servers/proxies. Last error was: Request 26 on chan 1 failed at Tue Mar 17 15:45:46 2015: -6 [fn-socket.c:112]: connect to 128.142.156.169 timed out after 5 seconds) ( CORAL : "coral::FrontierAccess::Statement::execute" from "CORAL/RelationalPlugins/frontier" )

CMS_8510_1426111757.078819_0

http://boincai05.cern.ch/CMS-dev/result.php?resultid=25309

Whenever I peek in at these systems, the server is partially idling, which is unusual with them running BOINC to consume all those spare cycles. The VM Guests with this type of error on the console seem to be waiting for something and not doing any actual work. With the virtualbox guest only consuming about 10% of a core.

Just wanting to share.


Next 20


©2024 CERN