Need som help exit code 114

Wim
Wim
Joined: 11 Mar 11
Posts: 7
Credit: 1562298
RAC: 0
Topic 220413

since the upgrade of the pc, windows reinstall and bonic transfer, I have run into this problem,
have already depleted the anitvirus (comodo)

but don't come out with the code below please help, thanks

Greeds, Wim

 

<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
De interne bestandsaanduiding voor het doelbestand is onjuist.
 (0x72) - exit code 114 (0x72)</message>
<stderr_txt>
putenv 'LAL_DEBUG_LEVEL=3'
2020-01-11 22:29:38.5600 (6604) [normal]: This program is published under the GNU General Public License, version 2
2020-01-11 22:29:38.5600 (6604) [normal]: For details see http://einstein.phys.uwm.edu/license.php
2020-01-11 22:29:38.5600 (6604) [normal]: This Einstein@home App was built at: Oct 24 2019 06:47:40

2020-01-11 22:29:38.5756 (6604) [normal]: Start of BOINC application 'projects/einstein.phys.uwm.edu/einstein_O2MDF_2.02_windows_x86_64__GW-opencl-ati.exe'.
Activated exception handling...
[DEBUG} GPU type: 2
[DEBUG} got GPU info from BOINC
[DEBUG} got VendorID 4098
2020-01-11 22:29:39.2475 (6604) [debug]: BSGL output files
2020-01-11 22:29:39.2475 (6604) [debug]: Flags: LAL_DEBUG, OPTIMIZE, HS_OPTIMIZATION, GC_SSE2_OPT, X64, SSE, SSE2, GNUC X86 GNUX86
2020-01-11 22:29:39.2475 (6604) [debug]: Set up communication with graphics process.

DEPRECATION WARNING: program has invoked obsolete function XLALGetVersionString(). Please see XLALVCSInfoString() for information about a replacement.
Code-version: %% LAL: 6.19.2.1 (CLEAN da7b29d537da983b9ab60a7f2a2a29fd91238c6a)
%% LALPulsar: 1.17.1.1 (CLEAN da7b29d537da983b9ab60a7f2a2a29fd91238c6a)
%% LALApps: 6.23.0.1 (CLEAN da7b29d537da983b9ab60a7f2a2a29fd91238c6a)

2020-01-11 22:29:40.4506 (6604) [normal]: Reading input data ... 2020-01-11 22:31:56.9975 (6604) [normal]: Search FstatMethod used: 'ResampGeneric'
2020-01-11 22:31:56.9975 (6604) [normal]: Recalc FstatMethod used: 'DemodSSE'
XLAL Error - XLALGetSelectedCLDEVICEName (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/OpenCLutils.c:1272): Check failed: ( device = XLALSelectCLDEVICE ( ) ) != ((void *)0)
XLAL Error - XLALGetSelectedCLDEVICEName (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/OpenCLutils.c:1272): Internal function call failed
2020-01-11 22:31:56.9975 (6604) [normal]: OpenCL Device used for Search/Recalc and/or semi coherent step: '(null)'
2020-01-11 22:31:56.9975 (6604) [normal]: OpenCL version is used for the semi-coherent step!
Error[1] -16: function LALDRunningMedian2, file /home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lal/src/utilities/LALRunningMedian.c, line 980, $Id$
ABORT: INITSTATUS: non-zero xlalErrno
XLAL Error - XLALPeriodoToRngmed (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:348): LALDRunningMedian2() failed with statusCode = -16
XLAL Warning - XLALSetErrno (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lal/src/std/XLALError.c:349): Ignoring previous error (xlalErrno=1024) Internal function call failed

XLAL Error - XLALPeriodoToRngmed (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:348): Generic failure
XLAL Error - XLALSFTtoRngmed (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:245): Call to XLALPeriodoToRngmed() failed.
XLAL Error - XLALSFTtoRngmed (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:245): Internal function call failed: Generic failure
XLAL Error - XLALNormalizeSFT (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:86): XLALSFTtoRngmed() failed
XLAL Error - XLALNormalizeSFT (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:86): Internal function call failed: Generic failure
XLAL Error - XLALNormalizeMultiSFTVect (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:203): XLALNormalizeSFT() failed
XLAL Error - XLALNormalizeMultiSFTVect (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/NormalizeSFTRngMed.c:203): Internal function call failed: Generic failure
XLAL Error - XLALCreateFstatInput (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/ComputeFstat.c:568): Check failed: (runningMedian = XLALNormalizeMultiSFTVect ( multiSFTs, optArgs.runningMedianWindow, optArgs.assumeSqrtSX )) != ((void *)0)
XLAL Error - XLALCreateFstatInput (/home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalpulsar/src/ComputeFstat.c:568): Internal function call failed: Generic failure
SetUpSFTs: XLALCreateFstatInput() failed with errno=1152Error[1] 14: function SetUpSFTs, file /home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalapps/src/pulsar/GCT/HierarchSearchGCT.c, line 2807, $Id$
ABORT: XLAL function call failed
Level 0: $Id$
Function call `SetUpSFTs( &status, &usefulParams )' failed.
file /home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalapps/src/pulsar/GCT/HierarchSearchGCT.c, line 1049

Level 1: $Id$
Status code 14: XLAL function call failed
function SetUpSFTs, file /home/jenkins/workspace/workspace/EaH-GW-OpenCL-Testing/SLAVE/MinGW6.3/TARGET/windows-x64/EinsteinAtHome/source/lalsuite/lalapps/src/pulsar/GCT/HierarchSearchGCT.c, line 2807
2020-01-11 22:31:58.2475 (6604) [CRITICAL]: BOINC_LAL_ErrHand(): xlalErrno = 1152
2020-01-11 22:31:58.2475 (6604) [CRITICAL]: BOINC_LAL_ErrHand(): now calling boinc_finish()
22:31:58 (6604): called boinc_finish

</stderr_txt>
]]>

Richie
Richie
Joined: 7 Mar 14
Posts: 656
Credit: 1702989778
RAC: 0

Hi!Boinc says your computer

Hi!

Boinc says your computer has "[2] AMD AMD Radeon HD 6900 series (Cayman) (1024MB) driver: 1.4.1848". It seems that your host has been trying to run 'Gravitational Wave search O2 Multi-Directional GPU v2.02 () windows_x86_64' tasks with HD 6900. That GPU has GCN 1.0 architecture. GPUs with GCN 1.0 have been observed to be incompatible with this current GW GPU app. That HD 6900 should be able to run FGRPB1G tasks succesfully though.

What's the second GPU in your computer ? You said there's been an upgrade. Do you mean that something was running successfully but not anymore after that upgrade? What exactly did you upgrade?

Wim
Wim
Joined: 11 Mar 11
Posts: 7
Credit: 1562298
RAC: 0

Hi Richi my other card is

Hi Richi

my other card is AMD 6850 I already had this

I have added a 2nd GPU the AMD 9650
upgrade the quadcore prossesors from 2.8 to 30 gig
install windows fresh on a ssd

Richie
Richie
Joined: 7 Mar 14
Posts: 656
Credit: 1702989778
RAC: 0

Okay. I believe you meant 2nd

Okay. I believe you meant 2nd GPU is 6950. I need to fix what I said earlier. Those 6800/6900 series AMD cards have actually TeraScale 3 architecture which is even older than GCN 1.0. They can only work with FGRPB1G (Gamma-ray pulsar binary search #1) tasks. If you want to use them you should uncheck all GW GPU apps and choose that pulsar app... at https://einsteinathome.org/account/prefs/project .

Wim
Wim
Joined: 11 Mar 11
Posts: 7
Credit: 1562298
RAC: 0

thanks, i have changed the

thanks, i have changed the settings.

how is it possible that with my old gpu
there were no problems

can you tel which GPUs can be used, for the rest

 

Thanks

Richie
Richie
Joined: 7 Mar 14
Posts: 656
Credit: 1702989778
RAC: 0

Wim wrote:how is it possible

Wim wrote:
how is it possible that with my old gpu there were no problems

The task list of your computer doesn't show anymore what app version the host was running back then. If I recall right, somebody else has written that an earlier GW GPU application used to work even with older cards. That was sometime in about November last year, when there was still a beta version of this GW GPU application.

Do you remember what exactly the card was running if the tasks run and validated succesfully? Or when was that, roughly?

Quote:
can you tel which GPUs can be used, for the rest

I don't know for absolutely sure where the line goes per card model, but at least some of the GCN 2.0 cards are able to run these current GW GPU tasks.

https://www.techpowerup.com/gpu-specs/?architecture=GCN+2.0&sort=generation

And newer generations ... GCN 3 ...GCN  4 etc. should work.

https://en.wikipedia.org/wiki/Graphics_Core_Next

Wim
Wim
Joined: 11 Mar 11
Posts: 7
Credit: 1562298
RAC: 0

thanks for the help, it

thanks for the help, it works, again as it did.

GW GPU application I'm going to look in the Gpus
 

Greeds Wim

Wim
Wim
Joined: 11 Mar 11
Posts: 7
Credit: 1562298
RAC: 0

Wim wrote:Hi Richi my other

Wim wrote:

Hi Richi

my other card is AMD 6850 I already had this

I have added a 2nd GPU the AMD 9650
upgrade the quadcore prossesors from 2.8 to 30 gig
install windows fresh on a ssd

 

by the way, I just see that I made a mistake

it must be (2nd GPU the AMD 6950)

 

 

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109396666695
RAC: 35784929

Wim wrote:... how is it

Wim wrote:
... how is it possible that with my old gpu
there were no problems

How is it possible for anybody to give you a proper answer?  You don't tell us exactly what you were crunching or when that was.  A lot has changed in the last few months.  A best guess would be that when "there were no problems", you were crunching only gamma-ray pulsar (GRP) GPU tasks and NOT any flavour of the more recent gravitational wave (GW) GPU tasks.  So the best guess for an answer is that things are a lot different now.

Looking at your current tasks list, which will be changing all the time, you have 36 GW GPU tasks, all compute errors, 3 GW CPU tasks, all currently in progress, and 4 GRP GPU tasks, 3 successfully completed and 1 in progress.  With your current hardware, you would seem to be able to crunch GRP GPU tasks and GW CPU tasks without problems.

However, you should be aware that both GPUs you have mentioned were released more than 9 years ago and are quite power hungry.  The HD6950 has a thermal design power (TDP) of 200 watts and the HD6850 is 127 watts.  The crunch time for your GRP tasks shows as between 70 and 75 minutes and we can't tell which GPU did the crunching.  I would expect a bigger range of values if both GPUs were working so I suspect that all 3 completed tasks were done by the one GPU.

You should take into consideration, the cost of power to run both GPUs (total TDP of 327W) when compared to what it would cost to run a single, more efficient and modern GPU.  Instead of crunch times of more than 70 mins, how would you like crunch times of around 10 mins from a single GPU with a TDP of 150W?  And as an added bonus, how would you like the ability to crunch the current GW tasks without error?

You already have a decent CPU, 3.0GHz Xeon (8 threads).  To run both your current GPUs, you must have a decent PSU capable of providing the 327W for your two GPUs.  You did confirm that before inserting the 2nd GPU, I hope :-).  If so, that PSU will have no problem running a more power efficient single GPU.  In recent times, I've been buying brand new AMD RX 570 GPUs for the equivalent of less than $US120.  That's a pretty cheap upgrade that would boost your output enormously and end up paying for itself quite easily in reduced power costs over its lifetime.

Cheers,
Gary.

Wim
Wim
Joined: 11 Mar 11
Posts: 7
Credit: 1562298
RAC: 0

thanks for your clear

thanks for your clear answer.

(this Gpu was not a wise choice)
I will soon be investing in the new (single) GPU RX570
the power consumption will then go down,

thanks for thinking along,
I will come back to it once the new GPU has been installed

Greeds Wim

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5842
Credit: 109396666695
RAC: 35784929

Wim wrote:thanks for your

Wim wrote:
thanks for your clear answer.

You are most welcome!

I was quite reluctant to make a recommendation since your experience may end up being different to my experience (hopefully not) and I always worry about the possibility of giving people misleading information.  However, in this particular case, the much improved performance and the very real power savings were compelling factors :-).

If you wish to see what is possible with an RX 570 GPU, here are a couple of examples.  This host has a single RX 570 and is crunching GW GPU tasks only, 3 tasks at a time (x3).  They take about 20 mins, so that's less than 7 mins per task.  The crunch time does vary, even for tasks that target a particular known pulsar as the potential source of the continuous GW.  It varies a lot more (as do the memory requirements) when targeting a different known pulsar.

There would probably be a gain in productivity from using a multiplicity of x4 at the moment but if the search switches to the Vela pulsar, x4 may give compute problems.  So I leave it at x3 (since I don't wish to have to continually monitor it) and there have been no compute errors or invalid results for a long time.  The current 4 listed "errors" are not client errors at all.  They are due to the disabling of a former feature which allowed the scheduler to "resend lost tasks".  If there happens to be a 'glitch' somewhere along the chain between the server and the client such that the client doesn't actually receive new tasks being sent, the scheduler doesn't try to resend them.  It now immediately drops them and calls them "Timed out - no response" errors.  The 4 "errors" that currently show for the above host are of this type - more accurately, server errors and not client errors.

This host has exactly the same hardware as the first example.  The difference is that it crunches only GRP tasks at x2.  Unlike the GW tasks situation, the improvement in productivity is not as large when going from x1 to x2 and very minor if going higher than x2.  The host doesn't have any compute errors but there are usually about 1% or so of results that are deemed invalid.  There is nothing wrong with the hardware - it's just due to the strictness of the validation process and the fact that different hardware/software combinations can give slightly different answers.  There is nothing of concern - it's just the nature of the beast :-).  This host is completing 2 tasks in just under 20 mins, so less than 10 mins per task.

It's interesting to note that with GRP tasks, GPU crunch times are very little influenced by the CPU architecture and require very little CPU support.  As an example, this host has a 2008 Q6600 CPU (2.4GHz) supporting the RX 570 GPU.  If you examine the crunch times, you will see once again 2 tasks completed in less than 20 mins with no compute errors and around the 1% or so of invalid results.  That machine started out as a CPU cruncher in 2008 and has crunched ever since.  About 2 years ago, I upgraded the PSU and installed an RX 570.  It continues to work very well.

I chose to show these examples, not just to demonstrate the likely performance, but also to make an important point.  The two GPU searches are radically different, in more ways than just crunch times and optimum task multiplicity.  Currently, the relationship between what the crunch time is estimated to be and what it actually will be, is markedly different for the two searches - so much so that it is likely to cause problems if you try to run them both on the one set of hardware.  They will interfere with each other, particularly if you are trying to have a stable and relatively accurate cache of work on hand.  This is precisely why I limit a given machine to just one search type.

To run them both together, you could choose to use x2 for both searches and lose some GW search productivity.  You would also need to limit work cache size to less than 0.5 days.  If you didn't do that there could be situations where you could have so much GW work on hand that it might not be able to be completed within the 7 day deadline.  Hopefully, this rather extreme mismatch between what an estimate says and what the actual crunch time turns out to be will get addressed at some point, hopefully soon :-).

Cheers,
Gary.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.