21) Message boards : CMS Application : Problems connecting to servers? (Message 51209)
Posted 28 Nov 2024 by Profile Guy
Post:
Because CMS appears to be using only 1 CPU I tried adjusting my app_config.xml to use 1 CPU for CMS jobs.
They all failed!
CMS multithread jobs need 4 CPUs (minimum).
It "looked" like it was working... But all have since failed with this logged in stderr -
2024-11-28 11:15:41 (18379): Guest Log: [INFO] CMS application starting. Check log files.
2024-11-28 11:27:55 (18379): Guest Log: [ERROR] VM expects at least 4 CPUs but reports only 1.
Changed it back to 4 CPUs & threads. All OK now!
But this is a waste of compute units (CPUs). Three CPUs are doing exactly nothing.
22) Message boards : CMS Application : Problems connecting to servers? (Message 51207)
Posted 28 Nov 2024 by Profile Guy
Post:
The CMS multithread tasks are using just 1 CPU at the moment.
The sysfolk must be sending out test jobs.

<stderr_txt>
2024-11-28 10:14:06 (15635): vboxwrapper version 26207
...
2024-11-28 10:15:35 (15635): Guest Log: [INFO] CMS application starting. Check log files.
2024-11-28 10:42:29 (15635): Guest Log: [INFO] glidein exited with return value 0.
2024-11-28 10:42:30 (15635): Guest Log: [INFO] Shutting Down.
2024-11-28 10:42:30 (15635): VM Completion File Detected.
2024-11-28 10:42:30 (15635): VM Completion Message: glidein exited with return value 0.
...

</stderr_txt>
The jobs are all completing and being verified successfully.
But note the timestamps - the jobs take a minute and a half to initialise, then 28 minutes to complete
23) Message boards : CMS Application : Problems connecting to servers? (Message 51200)
Posted 27 Nov 2024 by Profile Guy
Post:
From my All tasks web page -

Task          Work unit     Computer      Sent                          Time reported   Status                  Run     CPU     Application
                                                                        or deadline                             time    time
417388207     228404289     10860321      27 Nov 2024, 9:04:47 UTC      9:24:36 UTC    Error while computing    126.59  21.70   CMS Simulation v70.30 (vbox64_mt_mcore_cms)
                                                                                                                                x86_64-pc-linux-gnu

this is the error I'm seeing with CMS -

417388207 stderr output from above task.

The following error occurs towards the end of the above stderr output:
...
2024-11-27 09:22:20 (35388): Guest Log: [INFO] Testing connection to EOSCMS
2024-11-27 09:22:20 (35388): Guest Log: [DEBUG] Status run 1 of up to 3: 1
2024-11-27 09:22:26 (35388): Guest Log: [DEBUG] Status run 2 of up to 3: 1
2024-11-27 09:22:40 (35388): Guest Log: [DEBUG] Status run 3 of up to 3: 1
2024-11-27 09:22:40 (35388): Guest Log: [DEBUG] run 1
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Version 7.50 ( https://nmap.org/ncat )
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Connection to 128.142.160.140 failed: Connection refused.
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Trying next address...
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Connection refused.
2024-11-27 09:22:40 (35388): Guest Log: run 2
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Version 7.50 ( https://nmap.org/ncat )
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Connection to 128.142.160.140 failed: Connection refused.
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Trying next address...
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Connection refused.
2024-11-27 09:22:40 (35388): Guest Log: run 3
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Version 7.50 ( https://nmap.org/ncat )
2024-11-27 09:22:40 (35388): Guest Log: NCAT DEBUG: Using system default trusted CA certificates and those in /usr/share/ncat/ca-bundle.crt.
2024-11-27 09:22:40 (35388): Guest Log: NCAT DEBUG: Unable to load trusted CA certificates from /usr/share/ncat/ca-bundle.crt: error:02001002:system library:fopen:No such file or directory
2024-11-27 09:22:40 (35388): Guest Log: libnsock nsi_new2(): nsi_new (IOD #1)
2024-11-27 09:22:40 (35388): Guest Log: libnsock nsock_connect_tcp(): TCP connection requested to 128.142.160.140:1094 (IOD #1) EID 8
2024-11-27 09:22:40 (35388): Guest Log: libnsock nsock_trace_handler_callback(): Callback: CONNECT ERROR [Connection refused (111)] for EID 8 [128.142.160.140:1094]
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Connection to 128.142.160.140 failed: Connection refused.
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Trying next address...
2024-11-27 09:22:40 (35388): Guest Log: libnsock nsock_connect_tcp(): TCP connection requested to 2001:1458:301:17::100:9:1094 (IOD #1) EID 16
2024-11-27 09:22:40 (35388): Guest Log: libnsock nsock_trace_handler_callback(): Callback: CONNECT ERROR [Connection refused (111)] for EID 16 [2001:1458:301:17::100:9:1094]
2024-11-27 09:22:40 (35388): Guest Log: Ncat: Connection refused.
2024-11-27 09:22:40 (35388): Guest Log: [ERROR] Could not connect to eoscms-ns-ip563.cern.ch on port 1094
2024-11-27 09:22:40 (35388): Guest Log: [INFO] Testing connection to CMS-Factory
2024-11-27 09:22:41 (35388): Guest Log: [INFO] Testing connection to CMS-Frontier
2024-11-27 09:22:41 (35388): Guest Log: [INFO] Testing connection to Frontier
2024-11-27 09:22:41 (35388): Guest Log: [DEBUG] Check your firewall and your network load
2024-11-27 09:22:41 (35388): Guest Log: [ERROR] Could not connect to all required network services
...
24) Message boards : CMS Application : Problems connecting to servers? (Message 51182)
Posted 26 Nov 2024 by Profile Guy
Post:
Yes, Theory jobs run with one thread using exactly one CPU core.
Above, in the <app>..</app> section, the line
<max_concurrent>4</max_concurrent>
limits the number of Theory jobs that run at the same time - that, as you note, run in the form: 1 Theory work unit will use 1 CPU core.
So it is possible to have more than one Theory job running on your BOINC client at a time - well, if you have a multi-core CPU. Now with all the 'week long' Theory jobs that are being sent out now, it may be useful to allow other job types to run, even from other projects, at the same time as the long Theory jobs.
This
app_config.xml -
<app_config>

  <app>  
    <name>Theory</name>
    <max_concurrent>4</max_concurrent>
  </app>

</app_config>
limits the number of Theory jobs that run at the same time. And with one job per one CPU core, a maximum of 4 CPU cores will ever be used for Theory jobs with this app_config.xml in effect.
If you have any more cores available they will run other non-Theory job types. That's useful for running, if they're available, some different types of LHC@home tasks concurrently (at the same time) or to keep another projects tasks running while your PC concurrently crunches through some long LHC@home Theory tasks.

There are as many ways to use app_config.xml as there are different computers.
These examples are running well on my 8 core system.

Before anything else - it's recommended to leave a couple of CPU cores free to run all the background OS processes. A reliable way to do this is to use the BOINC Manager's "Options -> Computing preferences" to limit the number of CPUs that BOINC uses for its number crunching.
Use at most [75] % of the CPUs
works well with my 8-core CPU.

Multi-threaded tasks
NOTE that there are multi-threaded apps out there and they use completely different app_config.xml elements for limiting, if you want to, the number of CPU cores that a multi-thread task will use.
For instance two of the other job types offered by the LHC@home project are ATLAS and CMS. These job types are multi-threaded meaning that they use many of your CPUs per job. So just one of these multi-threaded jobs will try to use all the CPUs available to your BOINC client - leaving no room for anything else to run. This may suit your needs. In my 8-core multi project set-up I prefer a workload that's balanced across different app types and different projects. For me, that means limiting the number of any one particular type of app running at a time and limiting the total number of all apps any project can run concurrently. But if you're only going to run just one project you can leave out those last limits.
So, in the following app_config.xml the CMS tasks are limited with the <max_concurrent>1</max_concurrent> xml element to running 1 CMS job at a time. The <avg_ncpus>4</avg_ncpus> and <cmdline>--nthreads 4</cmdline> elements limit the number of CPU cores & threads it uses to 4. That allows other job types to run on your remaining free CPUs. Groovy.

app_config.xml
<app_config>

  <app>
    <name>CMS</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app_version>
    <app_name>CMS</app_name>
    <plan_class>vbox64_mt_mcore_cms</plan_class>
    <avg_ncpus>4</avg_ncpus>
    <cmdline>--nthreads 4</cmdline>
  </app_version>

  <app>
    <name>Theory</name>
    <max_concurrent>4</max_concurrent>
  </app>

</app_config>


You can do the same with ATLAS, like this -
app_config.xml
<app_config>

  <project_max_concurrent>4</project_max_concurrent>

  <!-- limiting the concurrent apps run by any one project above allows apps from other projects to run as well -->
  <!-- as long as they have work available. Optional -->

  <app>
    <name>ATLAS</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app_version>
    <app_name>ATLAS</app_name>
    <plan_class>vbox64_mt_mcore_atlas</plan_class>
    <avg_ncpus>4</avg_ncpus>
    <cmdline>--nthreads 4</cmdline>
  </app_version>

  <app>
    <name>CMS</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app_version>
    <app_name>CMS</app_name>
    <plan_class>vbox64_mt_mcore_cms</plan_class>
    <avg_ncpus>4</avg_ncpus>
    <cmdline>--nthreads 4</cmdline>
  </app_version>

<!-- This Theory app section is now superfluous because of line 3 -->
<!-- But if you only have LHC work, or have deleted line 3 -->
<!-- then you may find this section useful -->
  <app>  
    <name>Theory</name>
    <max_concurrent>4</max_concurrent>
  </app>
  <app_version>
    <app_name>Theory</app_name>
    <plan_class>vbox64_theory</plan_class>
    <!-- nothing to do here! -->
  </app_version>

</app_config>



Instructions for writing app_config.xml files are here.

If you want to write an app_config.xml for your project (or one each for more than one project!) -
to use it, you put it in its particular project folder, here:

Windows:
C:\ProgramData\BOINC\projects\<your project>\app_config.xml

Linux:
/var/lib/boinc/projects/<your project>/app_config.xml

Then start your BOINC client.
Or, if it's running already, click "Options -> Read config files" in your BOINC Manager.
And it takes effect.
25) Questions and Answers : Windows : Windows Theory Simulation v300.30 deadline miss (Message 51129)
Posted 24 Nov 2024 by Profile Guy
Post:
Also on the subject of very long running Theory tasks -
This gonna be long - https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=6251
And (currently) -
CMS and Atlas have problems, but I'm getting a few Theory jobs that seem to be running.

Have a little patience. They'll sort it out eventually.
26) Message boards : Theory Application : This gonna be long (Message 51128)
Posted 24 Nov 2024 by Profile Guy
Post:
Perfect. Thanks. ;-)
27) Message boards : CMS Application : Problems connecting to servers? (Message 51127)
Posted 24 Nov 2024 by Profile Guy
Post:
It's vexing.
Long running tasks and fair play - https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=6240
This gonna be long - https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=6251

If you get nothing but long Theory jobs using all your CPUs you could limit the number with
app_config.xml
<app_config>

  <app>  
    <name>Theory</name>
    <max_concurrent>4</max_concurrent>
  </app>

</app_config>
and thus allow other jobs to run at the same time. (4 is just an example. It depends on how many of your CPUs you are willing to give to Theory tasks.)

Create the above app_config.xml file and drop it in your LHC@home project data folder, here:
Windows:
C:\ProgramData\BOINC\projects\<your project>\app_config.xml
Linux:
/var/lib/boinc/projects/<your project>/app_config.xml

Instructions for writing app_config.xml files are here
28) Message boards : Theory Application : This gonna be long (Message 51125)
Posted 24 Nov 2024 by Profile Guy
Post:
Thank you. There it is!

61,600 of 100,000 events processed
5 days so far.
Started:.....19 Nov 2024, 14:21:01 UTC
Deadline:..30 Nov 2024, 14:21:01 UTC

(This is my only PC, so BOINC only runs for ~75% of the time.)

What happens to a Theory task? Do they just count to 100,000 [default] and stop?
29) Message boards : Theory Application : This gonna be long (Message 51116)
Posted 23 Nov 2024 by Profile Guy
Post:
Thanks for the responses.
I won't be able to implement this method -
I don't have
/var/lib/boinc/slots/*/cernvm
I do have
/var/lib/boinc/slots/*/shared
for the Theory task. But there's no runRivet.log or PanDA_Pilot anywhere. I searched for *event* and got nothing.
I do have a vague memory of being able to find the events processed in some xml file, without installing any extra software.
30) Message boards : Theory Application : This gonna be long (Message 51110)
Posted 22 Nov 2024 by Profile Guy
Post:
Sorry about the power failure.
Lem - please remind me - where do I find the "events" processed?
Thanks
31) Message boards : CMS Application : How do I limit the number of concurrent CMS VM's? (Message 51108)
Posted 21 Nov 2024 by Profile Guy
Post:
Extra app_config.xml info.

Where to put app_config.xml
It goes in its particular project folder, here:

Windows:
C:\ProgramData\BOINC\projects\<your project>\app_config.xml
Linux:
/var/lib/boinc/projects/<your project>/app_config.xml

Also -
Limit how much work you download.
It's important to note, obviously, the amount of work you choose to download should not exceed the ability of your PC to complete it in time, before its deadline.
Because if you do choose to get too many days worth of work your BOINC client (on your PC) will 'see' that it won't complete it in time. But it will try - it will "override" all your Preferences and app_config.xml settings and assign ALL(!) of your CPUs to the downloaded work units. And that clogs up your PC a bit. Slows it down. Why it lets you download too much I don't know. But that's how it works...

To manage this I've set the 'days of work' downloaded to a fractional value of 0.7 like this:

"Options -> Computing preferences..." then the Computing tab, in the General section:

Store at least [0.7] days and up to an additional [0] days of work

It's OK. It never runs out because BOINC checks about every hour or so and gets work from the project servers as often as it needs it. This way it just won't download "too much".

You may set yours differently. My modest 4GHz desktop PC has 6 of its 8 CPU cores enabled for BOINC, plus 1 GPU. And 0.7 days works well.

Instructions for writing app_config.xml files are here and, of course, further help can be gleaned if you ask on the forums.
32) Message boards : CMS Application : How do I limit the number of concurrent CMS VM's? (Message 51104)
Posted 20 Nov 2024 by Profile Guy
Post:
I have an 8 logical core CPU (i7-4790K) limited by BOINC to use just 6 of the CPUs (75%).
To limit the number of CPUs, use the BOINC Managers "Options -> Computing preferences".
It's recommended to limit the number of CPU cores used by BOINC so that essential Operating System background processes [and other programs] can run smoothly on those spare cores without interfering.

Aside: So thank you captain jack. And after some very helpful tutoring on the subject, I was able to tailor an app_config.xml file for each of my BOINC projects.

OK
Further limiting the concurrent apps run by any one project allows apps from other projects to run concurrently on the remaining CPUs as well.
Also, LHC@home has some multithreaded apps. By default, each one of those will try to use all available CPUs by itself.
So the following app_config.xml sets LHC@home up to use at most 4 of the 6 CPUs I've allowed for BOINC.
Like this:

Only 1 concurrent ATLAS task (1 Multithreaded task - Uses 4 CPUs)
or
Only 1 concurrent CMS task (1 Multithreaded task - Uses 4 CPUs)
or
Up to 4 concurrent Theory tasks. (Not Multithreaded - 1 CPU per task)

And the spare CPUs will run apps from other projects, if available.

app_config.xml
<app_config>  <!-- SuSE Linux Tumbleweed - no native apps -->

  <project_max_concurrent>4</project_max_concurrent>
  <!-- limiting the concurrent apps run by any one project allows apps from other projects to run as well -->
  <!-- as long as they have work available. Optional -->

  <app>
    <name>ATLAS</name>
    <max_concurrent>1</max_concurrent>
  </app>
  <app_version>  <!-- VM -->
    <app_name>ATLAS</app_name>
    <plan_class>vbox64_mt_mcore_atlas</plan_class>
    <avg_ncpus>4</avg_ncpus>
    <cmdline>--nthreads 4</cmdline>
  </app_version>

  <app>
    <name>CMS</name>  <!-- has VM tasks only -->
    <max_concurrent>1</max_concurrent>
  </app>
  <app_version>  <!-- VM -->
    <app_name>CMS</app_name>
    <plan_class>vbox64_mt_mcore_cms</plan_class>
    <avg_ncpus>4</avg_ncpus>
    <cmdline>--nthreads 4</cmdline>
  </app_version>

<!-- This 'app' section is superfluous because of line 3 -->
<!-- included for illustrative purposes only -->
  <app>  
    <name>Theory</name>
    <max_concurrent>4</max_concurrent>
  </app>
  <app_version>  <!-- VM -->
    <app_name>Theory</app_name>
    <plan_class>vbox64_theory</plan_class>
    <!-- nothing to do here either -->
  </app_version>

</app_config>

You may need to refer to the LHC@home Applications page if you're going to edit the app_config.xml file for yourself.
The "Version" column contains, in brackets, the "plan class" used in the app_config.xml file to identify the specific app you'll be sent automatically by BOINC depending on which OS and CPU you have.

I'm not running native apps because they take too long to run on my modest desktop PC.

Thanks to all.
33) Message boards : Theory Application : This gonna be long (Message 51102)
Posted 20 Nov 2024 by Profile Guy
Post:
Yep.

They're ironing out a few wrinkles at the moment.
The CMS task problem has apparently been fixed. But I've got to wait, hoping, for a "10 Day" Theory task to finish before I get to see any and find out!

Here's my list of failure -
https://lhcathome.cern.ch/lhcathome/results.php?userid=95350
LOL
34) Message boards : CMS Application : Problems connecting to servers? (Message 51101)
Posted 20 Nov 2024 by Profile Guy
Post:
Mine is still not working -

All Tasks

Checking the times on that... Ah.
OK There are, as I write this, reports it's working now...
[Preferences set to send me CMS...]

Frustrating.
I'll probably have to wait because there's a "10 Day" Theory task running at the moment! (See this post)
Yesterday I set the Project Preferences as below to stop sending me CMS tasks , but I still got them:
Run only the selected applications      SixTrack: yes
                                        sixtracktest: yes
                                        CMS Simulation: no
                                        Theory Simulation: yes
                                        ATLAS Simulation: yes
That's probably because of -
If no work for selected applications is available, accept work from other applications?        yes
Fun with a dash of very dry irony.
35) Message boards : CMS Application : Problems connecting to servers? (Message 51094)
Posted 18 Nov 2024 by Profile Guy
Post:
Thanks Ivan.
I do appreciate you reconfirming this!

The definitive answer is...
36) Message boards : CMS Application : Problems connecting to servers? (Message 51086)
Posted 17 Nov 2024 by Profile Guy
Post:
My computer:
OpenSuSE Tumbleweed [6.11.8-1-default|libc 2.40]
i7-4790k, 32 GB RAM, 2 TB M.2 SSD, nVidia RTX 2060 (driver: 550.99 OpenCL: 3.0).
Virtualbox (7.1.4_SUSEr165100)
BOINC version 8.0.4
Full spec: 10860321

My PC looks like this -

CMS tasks are failing to start.
For example:
Task          Work unit     Computer      Sent                          Time reported   Status                  Run     CPU     Application
                                                                        or deadline                             time    time
416651829     227670244     10860321      17 Nov 2024, 19:45:47 UTC     20:07:00 UTC    Error while computing   167.04  24.57   CMS Simulation v70.30 (vbox64_mt_mcore_cms)
                                                                                                                                x86_64-pc-linux-gnu
416648976     227667391     10860321      17 Nov 2024, 18:29:17 UTC     19:45:47 UTC    Error while computing   161.43  22.69   CMS Simulation v70.30 (vbox64_mt_mcore_cms)
                                                                                                                                x86_64-pc-linux-gnu
416646675     227665093     10860321      17 Nov 2024, 17:19:14 UTC     18:23:04 UTC    Error while computing   156.96  23.88   CMS Simulation v70.30 (vbox64_mt_mcore_cms)
                                                                                                                                x86_64-pc-linux-gnu

stderr for above tasks:
416651829
416648976
416646675

The following error occurs towards the end of each of the above stderr outpouts:
...
2024-11-17 20:03:37 (14664): Guest Log: [INFO] Testing connection to HTCondor
2024-11-17 20:03:53 (14664): Guest Log: [DEBUG] Status run 1 of up to 3: 1
2024-11-17 20:04:14 (14664): Guest Log: [DEBUG] Status run 2 of up to 3: 1
2024-11-17 20:04:39 (14664): Guest Log: [DEBUG] Status run 3 of up to 3: 1
2024-11-17 20:04:39 (14664): Guest Log: [DEBUG] run 1
2024-11-17 20:04:39 (14664): Guest Log: Ncat: Version 7.50 ( https://nmap.org/ncat )
2024-11-17 20:04:39 (14664): Guest Log: Ncat: Connection timed out.
2024-11-17 20:04:39 (14664): Guest Log: run 2
2024-11-17 20:04:39 (14664): Guest Log: Ncat: Version 7.50 ( https://nmap.org/ncat )
2024-11-17 20:04:39 (14664): Guest Log: Ncat: Connection timed out.
2024-11-17 20:04:39 (14664): Guest Log: run 3
2024-11-17 20:04:39 (14664): Guest Log: Ncat: Version 7.50 ( https://nmap.org/ncat )
2024-11-17 20:04:39 (14664): Guest Log: NCAT DEBUG: Using system default trusted CA certificates and those in /usr/share/ncat/ca-bundle.crt.
2024-11-17 20:04:39 (14664): Guest Log: NCAT DEBUG: Unable to load trusted CA certificates from /usr/share/ncat/ca-bundle.crt: error:02001002:system library:fopen:No such file or directory
2024-11-17 20:04:39 (14664): Guest Log: libnsock nsi_new2(): nsi_new (IOD #1)
2024-11-17 20:04:39 (14664): Guest Log: libnsock nsock_connect_tcp(): TCP connection requested to 137.138.156.85:9618 (IOD #1) EID 8
2024-11-17 20:04:39 (14664): Guest Log: libnsock nsock_trace_handler_callback(): Callback: CONNECT TIMEOUT for EID 8 [137.138.156.85:9618]
2024-11-17 20:04:39 (14664): Guest Log: Ncat: Connection timed out.
2024-11-17 20:04:39 (14664): Guest Log: [ERROR] Could not connect to vocms0840.cern.ch on port 9618
2024-11-17 20:04:39 (14664): Guest Log: [INFO] Testing connection to WMAgent
2024-11-17 20:04:39 (14664): Guest Log: [INFO] Testing connection to EOSCMS
2024-11-17 20:04:40 (14664): Guest Log: [INFO] Testing connection to CMS-Factory
2024-11-17 20:04:40 (14664): Guest Log: [INFO] Testing connection to CMS-Frontier
2024-11-17 20:04:40 (14664): Guest Log: [INFO] Testing connection to Frontier
2024-11-17 20:04:40 (14664): Guest Log: [DEBUG] Check your firewall and your network load
2024-11-17 20:04:40 (14664): Guest Log: [ERROR] Could not connect to all required network services
...

Any help with this would be welcome. Thanks.
37) Questions and Answers : Windows : Windows Theory Simulation v300.30 deadline miss (Message 50995)
Posted 2 Nov 2024 by Profile Guy
Post:
This problem is not limited to Windows.
So a more poignant post on the subject is here -

https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=6240
38) Message boards : Theory Application : Long running tasks and fair play (Message 50994)
Posted 2 Nov 2024 by Profile Guy
Post:
System: OpenSuSE Tumbleweed, Intel i7-4790K, 32GB, 2TB SSD

Me too. I've wasted a lot of time when a long Theory task times out.

For example,
my current BOINC Manager work status is -

(The date of this post: 02/11/2024)
Project     Status      Elapsed         Remaining (estimated)       Deadline        Application                                 Name

LHC@home    Running     6d 09:32:46     3d 11:55:01                 01/11/2024      Theory Simulation 300.30 (vbox64_theory)    Theory_2794-3266819-199_1
LHC@home    Running     5d 23:40:10     3d 21:55:48                 01/11/2024      Theory Simulation 300.30 (vbox64_theory)    Theory_2794-3257411-175_1

The LHC@home All tasks webpage (https://lhcathome.cern.ch/lhcathome/results.php?userid=95350)
shows this -
Task        Work unit   Computer    Sent            Time reported       Status                      Run time    CPU time    Credit      Application
                                                    or deadline                                     (sec)       (sec)

415137523   225914767   10860321    22 Oct 2024     2 Nov 2024          Timed out - no response     0.00        0.00        ---         Theory Simulation v300.30 (vbox64_theory)
                                                                                                                                        x86_64-pc-linux-gnu

415142791   226066966   10860321    22 Oct 2024    27 Oct 2024          Completed and validated     311,018.69  235,746.40  719.95      Theory Simulation v300.30 (vbox64_theory)
                                                                                                                                        x86_64-pc-linux-gnu

415137790   225932422   10860321    22 Oct 2024     2 Nov 2024          Timed out - no response     0.00        0.00        ---         Theory Simulation v300.30 (vbox64_theory)
                                                                                                                                        x86_64-pc-linux-gnu

No doubt the timed-out tasks would have eventually provided a valid result - if they'd have had more time.
Why not up the servers default response from 10 to 20 days?
39) Questions and Answers : Windows : Windows Theory Simulation v300.30 deadline miss (Message 50993)
Posted 2 Nov 2024 by Profile Guy
Post:
System: OpenSuSE Tumbleweed, Intel i7-4790K, 32GB, 2TB SSD

(The current date is 02/11/2024)

The BOINC Manager shows these running tasks:
Project     Status      Elapsed         Remaining (estimated)       Deadline        Application                                 Name

LHC@home    Running     6d 09:32:46     3d 11:55:01                 01/11/2024      Theory Simulation 300.30 (vbox64_theory)    Theory_2794-3266819-199_1
LHC@home    Running     5d 23:40:10     3d 21:55:48                 01/11/2024      Theory Simulation 300.30 (vbox64_theory)    Theory_2794-3257411-175_1

The LHC@home All tasks webpage (https://lhcathome.cern.ch/lhcathome/results.php?userid=95350)
shows this -
Task        Work unit   Computer    Sent            Time reported       Status                      Run time    CPU time    Credit      Application
                                                    or deadline                                     (sec)       (sec)

415137523   225914767   10860321    22 Oct 2024     2 Nov 2024          Timed out - no response     0.00        0.00        ---         Theory Simulation v300.30 (vbox64_theory)
                                                                                                                                        x86_64-pc-linux-gnu

415142791   226066966   10860321    22 Oct 2024    27 Oct 2024          Completed and validated     311,018.69  235,746.40  719.95      Theory Simulation v300.30 (vbox64_theory)
                                                                                                                                        x86_64-pc-linux-gnu

415137790   225932422   10860321    22 Oct 2024     2 Nov 2024          Timed out - no response     0.00        0.00        ---         Theory Simulation v300.30 (vbox64_theory)
                                                                                                                                        x86_64-pc-linux-gnu

No doubt the timed-out tasks would have eventually provided a valid result - if they'd have had more time.
Why not up the servers default response from 10 to 20 days?
40) Questions and Answers : Windows : Windows Theory Simulation v300.30 deadline miss (Message 50599)
Posted 1 Sep 2024 by Profile Guy
Post:
I'm speculating that the above warnings and errors are simulation telemetry and not program errors.
But the task is just going to carry on 'til the end, oblivious that it's gone past its deadline - a waste of time...


Previous 20 · Next 20


©2025 CERN