Pascal again available, Turing may be coming soon

Thank you Juha.  I think I now have a portable test case.

You mentioned

but I failed to register the implication.

Using this method the command line directive of the form --device 1 does not take precedence over the pair of lines:

<gpu_device_num>0</gpu_device_num>
<gpu_opencl_dev_index>0</gpu_opencl_dev_index>

in init_data.xml.

Otherwise, the new test directory I created on a second system (which runs a 1060 3GB + a 1050) appears to work (and to fail) properly on my primary system which runs a 2080 + a 1060. (I just modified the two lines mentioned in init_data.xml as required)

I intend a further portability test by burning the proposed test directory to a CD, and using it to create a test trial on my third system (which runs only a single 1050).

If all seems well, I intend to look into the suggestions on submitting a driver error report which are shown at the Nvidia Reddit forum.  I am pessimistic that the Nvidia team will even look at an end-user report that is so remote from their game core market in this busy time after a major generation introduction, but I feel it my duty to make the attempt.

Meanwhile, in order to allow my primary machine to continue doing Einstein work during this period of high-pay work unit distribution, I intend to swap out the 2080 for my 1070 later today.

I today sent PM messages to Bruce and -= Vyper =- at SETI asking whether they would be willing and able to try running my test case.  Unzipped it is under a dozen files and under 20 megabytes, so I think I can just copy it to a server where I buy space to post weather data, and point them to it, if either is willing and able.

Thanks for your report.  It appears to show your 2080 failing on the same type of WU in the same way as does my 2080.  This makes it extremely unlikely that the problem is one of a happenstance defect on my personal sample of the 2080.  (so I am glad I did not RMA it)

I have trimmed the stderr output you have posted to the portion which seems to contain the clear indication of failure above, and I am reproducing below the strikingly similar corresponding portion of a stderr from one of my "high-pay WU" 2080 failures:

% 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 -82224864
12:04:33 (9900): [CRITICAL]: ERROR: MAIN() returned with error '-36'
FPU status flags: PRECISION
12:04:45 (9900): [normal]: done. calling boinc_finish(28).
12:04:45 (9900): called boinc_finish

Aside from the similarity of stderr, it appears on a brief review of the tasks lists for your machine that it usually successfully completes what I have here called "low-pay" WUs for example from the LATeah1029L group, while it universally fails the dozens of "high-pay" WUs it has tried so far, from the LATeah0104R and LATeah0104S groups. Further the "high-pay" failures show elapsed times of 19 to 25 seconds, which is quite close to my observations.

As the "high-pay" type of WU is the current type being distributed here at Einstein, you may have little hope of successful completions other than luckily picking up a few resends of low-pay WUs needing an extra host completion to complete the quorum in cases of failure to reply or failure to meet sanity checks or failure to agree.

That looks like a bug in the Asteroids software, which appears not to interpret the reported compute capability of 7.5 as being "better than CC2.0".  That seems likely to be a different problem than the one in running high-pay Einstein WUs.