My troll radar starts pinging when after two days the OP still hasn't posted the most important and obvious
piece of information, even after being asked.

Anyway it's not the Cuda version it was compiled with that's important, it's the compute capability(s) it
was compiled for.

GPUs will only support compute capabilities equal to or below their spec. The miner must be compiled with,
at least, one compute capability supported by the GPU. When multiple versions are supported the highest
supported version will be chosen at run time.

https://developer.nvidia.com/cuda-gpus

To run a pre-compiled miner you don't need the Cuda toolkit, just the latest Nvidia driver. If the miner you're
using doesn't support your GPU (the one we still don't know the model of) then you need to find
a miner that does or compile one from source with a supported compute capability, if the source code is
available.

To compile from source you will need Cuda toolkit and a lot more. Even then the source code may not support
the older compute capability. If the miner is young it may not support old cards at all.

All the VS files are garbage, the project needs to be rebuilt from scratch.
Even so the code probably wouldn't compile due to incompatibilities
introduced over time.

It would be a bigger task than trying to compile on Apple Mac which a few have tried and
given up.

The process of using a Linux VM to cross compile using mingw is a lot of work to setup but
once done it's trivial to compile new versions. It's essentially 3 commands now to build the
binary release package.

With ASICs and FPGAs taking over more and more algos I'm not so sure.

I disagree. Dual mining is not discussed that much. It's a wothwhile topic. The spammers are the ones that
only criticize the idea as a waste of time.

Sure it can be done but it's dependent on task scheduling. Anytime a GPU miner's CPU thread has to wait
is dead time that reduces the effective hash rate. Running the CPU miner at a lower priority will usually
eliminate any scheduling latency for the GPU.

CPU mining on a dedicated GPU rig (more GPUs than CPU cores) is not advised.
Although GPU mining hardly uses any CPU you still want the CPU to be responsive
whenever it's needed.

Whatever, test it and see how much CPU mining affects GPU mining  performance.
Different algos mined on the CPU will have a different impact on GPU performance.

Randomx is under heavy development. I'm waiting until the dust settles to look at it in any detail.

Power efficiency can be a double edged sword, it could mean the GPU can't run
all cores full throttle due to resource limitations like memory.

There are miners and there are mining managers. Most mining managers also have built in
miners and/or can be configured to use 3rd party miners. There are several promoted in this forum
with built in 3rd party miners for AMD, Nvidia and CPU. Nicehash miner uses its own builtin miners.

cpuminer-opt-3.9.8

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.9.8

Changes to log output to provide data more relevant to actual mining performance.
phi2 can now handle pools with a mix of coins that use and don't use roots.
phi2-lux added as an alias for phi2 as they are identical except for roots.
Add x16rv2 algo for Ravencoin fork.

Detailed notes...

Please read the folllowing before reporting log questions.

The main motivation for the log changes was to focus on data that the pool uses to calculate earnings instead
of the traditional hash rate displayed by most miners. That hash rate is calculated by the miner counting hash
iterations over time.

Pools use the rate of share submission over time and the stratum difficulty to determine a user's share of a block.

As a result more focus has been placed on these data with the addition of detailed timing data in the 5 minute
summary report.

The diff adjusted average share submission rate is converted to a share equivalent hash rate and displayed in the
summary report. The miner reference hash rate is also displayed there for comparison and monitoring of CPU performance.
The miner reference hash rate is also displayed in the TTF calculation of the block report as it is used to
calculate the TTF for a block and share. The share equivalent hash rate should better match the pool's reported hash rate.
Although most pools use a 5 minute window they are not synchronized with the miner and will sometimes differ.
Edit: The summary data will be inacurrate if the stratum difficulty changed during the period.

A share's difficulty is also not used by the pool, unless it solves a block, and is no longer displayed on the first line of the
share report. The display of share difficulty and share ratio is FYI only due to it's lack if significance and is suppressed
if --quiet option is used.

The first line of the share report focusses on time, displaying the time since the last share and the network latency,
the time between submitting the share and receiving the reply from the pool. Timing information is also prominent
in the summary report.

Some compromises were made to avoid adding too much overhead that could reduce mining performance. For example the 5
minute summary is not exactly 5 minutes. Also, at startup block reports will show some zero values until a baseline
reference hash rate has been calculated. This can take a few minutes.

Everything else should be intuitive or easilly deduced if you've mined before. If you still can't figure it out please ask.

Thanks, I should have realized that. I'll make the change in cpuminer-opt.

Edit: phi2-lux now makes sense, it's just a workaround for phi2 with roots enabled for miners
that can't handle them dynamically.

Simple problem, simple fix but what's the connection to profit swicthing?

If iBeLink has anounced it it's not a rumour, it's fact. Where did the rumour originate?
Is it your own speculation?

There's nothing in x16rv2 that makes it more technically difficult than x16r to implement on ASIC or FPGA.
It's probably only a matter of time and demand.

If you don't produce a source it usually means you're starting the rumour.

Are you mining when it shuts off? Does it shut off if left idle?
What does it take to bring it back to life? Reboot? Power cycle?

Are the risers powered or do they draw power from the PCIe slot?

It seems like power is being shut off to the card but if it's powered
correctly I see no reason why.

Since you tried all the other PCIe slots (I presume all are x1 and require a riser)
try the GPU in the x16 slot using a riser instead of a direct connection. Since
it works when connected directly it will prove one way or another if it's a riser
problem.

Something else you can do is try to artificially reproduce the same symptoms.
With the card up and running disconnect the power cable from the riser.
Do it again but disconnect the data cable.

After a pause I've seen a couple in the past week. Stay alert.

I'm having a hell of a problem getting ccminer to work.

CPU: Ryzen7 1700
OS: Ubuntu 18.04
Cuda: 9.1 from repo
GPUs: GTX-1080ti, GTX-970
Source: https://github.com/zcoinofficial/ccminer/archive/1.2.2.tar.gz
Makefile: compute 5.2, 6.1  (removed 7.5)

There's nothing unusual with my setup, it works fine for other ccminer forks.

ccminer-1.2.2 segfaults on stratum thread startup. It looks like the URL wasn't set.
Previous versions have other problems.

Precisely. You can build a Nvidia-only proof of concept, but a real product will need
it's own pseudo language that can be compiled to ptx/cuda, ocl, and x86 native instructions
producing identical functionality. The language would have to complex enough (in the CISC sense)
that the FPGA can't decode with a simple table lookup. That's a hell of a lot of work.

I'm considering more changes to the share display to address 2 specific issues.

1. Share difficulty is not used by pools except when it solves a block. All valid shares are
otherwise considered equal regardless of difficulty. This makes the sharediff and share ratio
(block %) irrelevent. I am proposing eliminating the  reporting of share ratio and removing
the colour ranking from the share diff. The share diff will still be reported without any
highlighting for high diff shares.

This creates a bit of a dilema for calculating the effective share hash rate as it uses the
sharediff as well as time while the pool uses only time. To match the pool's calculations
I would need to know the expected share rate, which is not available to the miner AFAIK.
The existing calculation using share diff seems to track the pool's reported hashrate fairly
well in the summary report so until I find a better way I won't change it.

2. Job ID reporting was introduced due to a specific issue with persistent stale shares in
one pool affecting a couple of algos. I've debugged down to the stratum/curl level and
it appears the pool is sending stale jobs. There has been little interest from the pool admin
in pursuing this issue but all indications are it's a pool issue.

The only other benefit to job id reporting is to confirm expected stale rejects where it shows
a new job received between the submission of a share and it's acceptance by the pool.
I don't think this is enough to justify the added verbosity in the output. I am proposing to remove
all reporting of job ids.

I am aslo planning on removing the timestamp on all lines of a multiline report. Only the first
line will have a timestamp.

I may also make some changes to the share rate reporting to place more emphasis on this statistic
as it has a direct effect on mining performance.
Comments?

The point s that it's only Nvidia GPU architectures. No ASIC, no FPGA, no Radeon, no CPU.

"Tom" has an interesting arcticle about how Ryzen 3xxx achieved it's single thread performance and why
many users claim it fails to achieve its adverstised boost frequency.

In short they loosened their binning specs and typically have only one core that can achieve the
the boost rate. It's up to the OS to make sure lightly threaded applications always use the golden core.

It is rumoured Intel will dramatically cut the prices of Cascade Lake X to better compete with Threadripper 3.
If so they'll likeky cut the prices of the existing masinstream line as well.

From a CPU mining perspective it still looks like Ryzen has the edge. Ryzen's failings, particularly slow AVX2
and lack of AVX512, mostly affect algos that are now dominated by ASICs. AMD likely has room to cut prices
to respond to anything Intel does.