All WUs on RTX 2070 Error Out

I just started seeing that too, though it appears for entirely different reasons on my GTX 1060 (Win7 64-bit).

I am tempted to say that they should add more paper.

<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
The printer is out of paper.
 (0x1c) - exit code 28 (0x1c)</message>
<stderr_txt>
14:50:10 (3004): [normal]: This Einstein@home App was built at: Feb 15 2017 09:23:49

14:50:10 (3004): [normal]: Start of BOINC application 'projects/einstein.phys.uwm.edu/hsgamma_FGRPB1G_1.20_windows_x86_64__FGRPopencl1K-nvidia.exe'.
14:50:10 (3004): [debug]: 1.1e+016 fp, 4.2e+009 fp/s, 2485530 s, 690h25m29s55
14:50:10 (3004): [normal]: % CPU usage: 1.000000, GPU usage: 1.000000
command line: projects/einstein.phys.uwm.edu/hsgamma_FGRPB1G_1.20_windows_x86_64__FGRPopencl1K-nvidia.exe --inputfile ../../projects/einstein.phys.uwm.edu/LATeah1025L.dat --alpha 1.41058464281 --delta -0.444366280137 --skyRadius 5.090540e-07 --ldiBins 30 --f0start 92.0 --f0Band 8.0 --firstSkyPoint 0 --numSkyPoints 1 --f1dot -1e-13 --f1dotBand 1e-13 --df1dot 2.512676418e-15 --ephemdir ..\..\projects\einstein.phys.uwm.edu\JPLEPH --Tcoh 2097152.0 --toplist 10 --cohFollow 10 --numCells 1 --useWeights 1 --Srefinement 1 --CohSkyRef 1 --cohfullskybox 1 --mmfu 0.1 --reftime 56100 --model 0 --f0orbit 0.005 --mismatch 0.1 --demodbinary 1 --BinaryPointFile ../../projects/einstein.phys.uwm.edu/templates_LATeah1025L_0100_7122577.dat --debug 1 --device 0 -o LATeah1025L_100.0_0_0.0_7122577_1_0.out
output files: 'LATeah1025L_100.0_0_0.0_7122577_1_0.out' '../../projects/einstein.phys.uwm.edu/LATeah1025L_100.0_0_0.0_7122577_1_0' 'LATeah1025L_100.0_0_0.0_7122577_1_0.out.cohfu' '../../projects/einstein.phys.uwm.edu/LATeah1025L_100.0_0_0.0_7122577_1_1'
14:50:10 (3004): [debug]: Flags: X64 SSE SSE2 GNUC X86 GNUX86
14:50:10 (3004): [debug]: Set up communication with graphics process.
boinc_get_opencl_ids returned [00000000012147F0 , 0000000001214430]
Using OpenCL platform provided by: NVIDIA Corporation
Using OpenCL device "GeForce GTX 1060 6GB" by: NVIDIA Corporation
Max allocation limit: 1610612736
Global mem size: 2147483648
OpenCL device has FP64 support
% Opening inputfile: ../../projects/einstein.phys.uwm.edu/LATeah1025L.dat
% Total amount of photon times: 8950
% Preparing toplist of length: 10
% Read 1631 binary points
read_checkpoint(): Couldn't open file 'LATeah1025L_100.0_0_0.0_7122577_1_0.out.cpt': No such file or directory (2)
% fft_size: 16777216 (0x1000000); alloc: 67108872
% Sky point 1/1
% Binary point 1/1631
% Creating FFT plan.
% fft length: 16777216 (0x1000000)
% Scratch buffer size: 136314880
% Starting semicoherent search over f0 and f1.
% nf1dots: 41 df1dot: 2.512676418e-015 f1dot_start: -1e-013 f1dot_band: 1e-013
% Filling array of photon pairs
ERROR: /home/bema/fermilat/src/bridge_fft_clfft.c:948: clFinish failed. status=-36
ERROR: opencl_ts_2_phase_diff_sorted() returned with error 7343555
14:50:15 (3004): [CRITICAL]: ERROR: MAIN() returned with error '-36'
FPU status flags: PRECISION
14:50:26 (3004): [normal]: done. calling boinc_finish(28).
14:50:26 (3004): called boinc_finish

https://einsteinathome.org/host/12599270/tasks/6/0

You should just ignore this.  This is Windows taking an exit code that is nothing to do with Windows and misinterpreting it.  The exit code belongs to the app and is probably specific to some OpenCL internal problem within the app itself.  No doubt it would mean something to the Devs which is why it's being reported back to the project as part of the <stderr_txt> output stream.

Presumably this :

" ..... % Starting semicoherent search over f0 and f1.
% nf1dots: 41 df1dot: 2.512676418e-015 f1dot_start: -1e-013 f1dot_band: 1e-013
% Filling array of photon pairs
ERROR: /home/bema/fermilat/src/bridge_fft_clfft.c:948: clFinish failed. status=-36
ERROR: opencl_ts_2_phase_diff_sorted() returned with error 7343555
14:50:15 (3004): [CRITICAL]: ERROR: MAIN() returned with error '-36'
FPU status flags: PRECISION
14:50:26 (3004): [normal]: done. calling boinc_finish(28).
14:50:26 (3004): called boinc_finish"

 ... gives the clue that the OpenCL fast fourier transform is what is vomiting. The was an almost identical error reported last year by Archae86. Peter do you remember what was the conclusion drawn, if any, from that thread ?

I'll take a stab and say that ( some of ) the current Nvidia drivers aren't supporting OpenCL properly ( not withstanding hardware problems with RTX ). 

Cheers, Mike.

Thank you Richard. I've found out what the "-36" error really means, see this post : 

"... openCL specific and translates to CL_INVALID_COMMAND_QUEUE ...."

at Nvidia there is an explanation of this relating driver reset to work size eg. probably our shorties low pay vs longies high pay WUs. More or less means the driver restarts if something takes 'too long'. Perhaps this is under developer control ie. change the timeouts, see TdrDelay and TdrDdiDelay  here for Windows ? :-)))

Cheers, Mike.

( edit ) Begs the question as to how many, if any, are Linux machines with this error variety.

( edit ) E@H can generate large FFTs with long signal integrations, say, 2²² data points.

( edit ) Of course if there is no paper available then it will hang while waiting for some to be delivered, thus maybe triggering a reset too .... :-)))

LOL. Absorbent hand-towel to cleanup after driver messes. ;=}

Cheers, Mike.

( edit ) FWIW : on NVidia cards OpenCL is implemented using CUDA calls underneath and so :

- OpenCL will never beat CUDA

- if the CUDA aspect of a driver is bad then so will the OpenCL

- a single crappy CUDA core may break an OpenCL application eg. all the other cores working have completed bar the bad core and thus futilely await the exit barrier of the parallel portion of the code ( all need to complete before any proceed beyond ). So timeout occurs. The crappiness of a given CUDA core may be clock frequency dependent .