LHC@home

This new version updates the CVMFS cache and will hopefully solve the x509 errors some have been seeing.

well, the new version seems to create new problems, though,

see here: https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5075

okay, I solved the problem on the one machine which obviously had a too old VB. I installed VB 5.2.30, and now the tasks got started well.

However, on the other machine which has a newer VB version and started picking up Theory 263.95 yesterday, the first task failed after 11 hrs. 52 minutes:
197 (0x000000C5) EXIT_TIME_LIMIT_EXCEEDED

https://lhcathome.cern.ch/lhcathome/result.php?resultid=236590976

What kind of problem is this now?

Before, we had the DISK_LIMIT_EXCEEDED problem, now we have this :-)

So far I have 5 of this version finished and ALL are Valid

And this is with Windows 7 and 10 and with 1,2, and 4 core tasks and I should have many more getting close to complete so I hope to see them all Valid

(glad that helped with yours Erich )

okay, I solved the problem on the one machine which obviously had a too old VB. I installed VB 5.2.30, and now the tasks got started well.

However, on the other machine which has a newer VB version and started picking up Theory 263.95 yesterday, the first task failed after 11 hrs. 52 minutes:
197 (0x000000C5) EXIT_TIME_LIMIT_EXCEEDED

https://lhcathome.cern.ch/lhcathome/result.php?resultid=236590976

What kind of problem is this now?

Before, we had the DISK_LIMIT_EXCEEDED problem, now we have this :-)

Well you do have VB version. 5.2.8 on there so maybe a clean install with 5.2.30 on there too.

https://www.virtualbox.org/wiki/Download_Old_Builds_5_2

Don't know why Erich's one exceeded time limit as it didn't even get as far as the 12hr check.
First 2 of mine completed and validated successfully here and here

Win10, Boinc 7.14.2, VBox 6.0.8

Don't know why Erich's one exceeded time limit as it didn't even get as far as the 12hr check.

yes, this is really strange.
There are several others running right now, one close to 9 hours, the other one close to 6 hours. So I'll wait and see what happens.
Maybe the VB version indeed needs to be updated.

Well you do have VB version. 5.2.8 on there so maybe a clean install with 5.2.30 on there too.

I just notice that on another of my machines, a 263.95 task got finished valid with VB version 5.2.8 (which is the one which currently comes along with BOINC).
see here: https://lhcathome.cern.ch/lhcathome/result.php?resultid=236579157

So obviously, this version is NOT the reason for EXIT_TIME_LIMIT_EXCEEDED error.

So obviously, this version is NOT the reason for EXIT_TIME_LIMIT_EXCEEDED error.

The reason is in the result log (and in your BOINC Manager event log).

exceeded elapsed time limit 42731.11 (2000000.00G/128.20G)</message> ===> 42731 seconds is 11.87 hours.

The problem is that somehow BOINC had info that your machine has measured a floating point speed of 128.2G.

Now your host reports 3.9 billion ops/sec. With your actual speed the task is allowed to use > 142 hours.

thanks, Crystal Pellet, for the explanation.
So the question is: what can be done in order to get this problem resolved?

So the question is: what can be done in order to get this problem resolved?

It's your machine reporting that's such a fast beast, so tame that beast ;)

so, here the next 2 which failed, this time after 4 hrs 20 mins:

https://lhcathome.cern.ch/lhcathome/result.php?resultid=236600271
https://lhcathome.cern.ch/lhcathome/result.php?resultid=236602102

which is rather annoying.

Still my opinion is that the problem must be with the new version 263.95, since all tasks before under version 263.90 worked well.
So obviously version 263.95 need to be re-designed.

Did you recently play around with the #core setting (either on the web page or via app_config.xml)?
If yes, this could result in a very high peak FLOPS value that is stored in the computer record.
If this value is not too high you simply get more credits per task.

Another reason could be a couple of tasks with very short runtimes that validated somehow.

BTW:
The stored peak FLOPS is different from what you see at the computer page.
It's a calculated value based on your runtimes/CPU-times.

Did you recently play around with the #core setting (either on the web page or via app_config.xml)?

no, I did not

If yes, this could result in a very high peak FLOPS value that is stored in the computer record.

Good point!

In Erich's result 1830MB RAM is reserved (Setting Memory Size for VM. (1830MB)), what implies that 12 cores seem to be reserved.

Erich what happens when you set in your preferences # of cores to 1?

In the web settings, I have number of tasks and number of cores set to "unlimited".

This was the advice we got here in the forum, several months ago, after suddenly there ocurred problems with the number of tasks that could be downloaded at a time. From what I remember, with the host in question here I could download only 2 tasks at a time, although my CPU has 6+6HT cores (and I normally crunch between 5 and 7 tasks concurrently).
In order to limit the number of simultaneously running tasks plus limit the number of cores to 1 per task, I am using an app_config.xml (which was also published here at that time).

The same setting I have with another host, with which, as mentioned above, the tasks from version 263.95 finish sucessfully.
And, as also already stated, this setting worked well with version 263.90 until 2 days ago.

Nevertheless I will try CP's suggestion to set # cores to 1. So let's see what happens.

... So let's see what happens.

At least ATLAS will also limit the # of tasks you can download.
As mentioned a couple of times this is caused by the fact that ATLAS doesn't correctly respect the #cores parameter (as it was originally introduced).

This affects computers with lots of cores more than computers with less cores.

At least ATLAS will also limit the # of tasks you can download.

yes, I know :-)

Nevertheless I will try CP's suggestion to set # cores to 1. So let's see what happens.

after I saw that all currently downloaded tasks failed after a certain time, I aborted the remaining ones, changed the # cores to "1" in the web preferences, and downloaded new tasks.
So I'm curious what I'll see.

... So let's see what happens.

At least ATLAS will also limit the # of tasks you can download.
As mentioned a couple of times this is caused by the fact that ATLAS doesn't correctly respect the #cores parameter (as it was originally introduced).

This is an ongoing problem that can be compensated for but it's confusing for a lot of volunteers. It really needs to be fixed.
Laurence, while we have your attention?