I presume those numbers are btc/GH/s/d. They seem way off compared with a week ago on yaamp
and what is currently reported on miningpoolhub (SRC .32, QRK .22). And I have no idea about SAK
except that I can't find anywhere to trade it.

It seems lyra2 is memory bound. Unless the 960 has more memory I wouldn't expect a big increase, but I
wouldn't expect a decrease either.

You need to enable compute 3.0 in  Makefile.am. There is some discussion on how to do this earlier
in this thread. I have no 3.0 cards but I can confirm it works on 3.5. Also stick with cuda 6.5 for now.

FYI this isn't the kind of problem that warrants a ticket. Besides the fact that you ticketed the wrong
fork SP is focussed on 5.0 and above and unlikely to respond to a problem affecting other compute
versions, even a legitimate problem.

However, you're in the right place now. Be sure to post your results.

Edit: Ooops, cuda 6.5 not available on Redhat 7

Yes, I know that. The page I pointed to lists the algo normalization factors so you can compare the profitability
among all the aglos.

Now if only the pool would come back up.

That looks like a problem with  the  ccminer executable. Try recompiling or redownloading as appropriate.

I had assumed the 970 TDP would be within the 145W Nvidia spec except if OCed. It seems that
assumption was way off. I didn't find an actual TDP spec for this card, just PSU and connector reqs.
Is it really 250W? This changes the balance of power (bad pun) and makes me wonder about the 980
rated at 165W.

If gave you that impression it was not my intent. There are several reasons the focus is on SP. First it's his thread
about his release. It's also the most popular fork at the moment and the center of most of the discussion. It is
also my impression that it is the most complete open source version of ccminer and that optimizations,
new kernels, etc, written by other devs will be merged by SP. If there are other open source forks that have advantages
over SP's I am not aware of them. Even if there are I don't think it would be fair to SP to hijack his thread to
discuss another fork of ccminer at length.

However, I do take notice when SP posts that he has imported code from another dev. And I do visit the gits of
these devs to see what else they are up to.

Yikes, even worse distribute with their own fee replacing the dev's. That's really low.

For the record I'm not against a fee of some sort but I do prefer open source. The problem with
combining the two is, as wolf0 pointed out, that anyone can code out the fee.

Not quite. Everyone has a CPU, many have a GPU, few have an ASIC miner. As you go up the ladder you shrink
the user base. Optimizing the lower end slows that arms race. Whether it can stop it can be argued but 1 1/2
years later there is still no x11 ASIC AFAIK.

True, a coin that is first to use an algorithm needs to have a functioning miner but the coin devs don't
seem very interested in optimized miners. Their fear of ASICs, and to a lesser extent GPUs means
they choose algos that are particularly difficult to optimize, which in turn means only the most talented
coders can implement those optimizations. I'm not suggesting coin devs lead the charge to ASICS but
they should try to keep open source miners at optimum to discourage the development of
private kernels and ASICs which tilt the playing field.

Many have interpreted this as meaning you will go closed source. To me it looks more like you think
you won't be able to compete with the devs of private kernels in the next round of optimizations for Pascal.
I hope this is just a temporary lack of confidence because your contribution to Maxwell has been
invaluable and would be equally welcomed on Pascal.

The problem with miner development is it's extremely competitive. If I build a better miner it is in
my selfish interest to keep it to myself. I can mine at higher efficiency while facing less competition
from other miners. If I give it away I lose my competitive advantage. If I sell it I still lose my mining
advantage but I can still profit from my work.

Open source miner developers should be commended for their generosity. Not only do they forgo profit
for themselves they make the mining environment better for everyone. Their continued presence also
keeps the closed source devs honest.

An alternative funding scheme I would like to propose is that coin devs and rental services get more involved
in funding open source development. Coin devs would have an interest in keeping the mining environment
for their coin fair. An elitest environment where only those who pay get good mining performance would
be seen as unfair and would discourage many miners. Rental services like Nicehash would also have an
interest in promoting more efficient miners to their users. In both cases there is no incentive to keep better
miners secret.

I would like to give a shout out to chrysophylax who is a coin dev, farm operator and major donator to
open source ccminer. If other coin devs would get similarly involved it might be enough to get some of the
closed source miners opened.

To yaamp:

What's up with SAK? I was mining quark when SAK went live and got a share of the first block (1773850)
but then it just vanished from my earnings. The pool shows the block as matured. Where did my share go?

You should be getting around 16,000 KH/s quark on a 970. I'm not sure what could cause that sort
of deficit.  That seems too much for throttling. The old version of ccminer might  do it but I assume
that's not the case. An incorrectly compiled ccminer, omitting compute 5.0 & 5.2, might do it.
The CPU or GPU bogged down by other processes is also a possibility.

Do you have any other cards, how do they hash?

Yes, fairly new. Since most people have 9xx cards now it only makes sense. The Windows binaries have
had compute 5.2 for a while, you would only run into problems if you tried to compile.

You need the version of cuda 6.5 that supports 9xx cards.

https://developer.nvidia.com/cuda-downloads-geforce-gtx9xx

If you don't have any 9xx cards you can remove compute_52 from Makefile.am.
Edit: assuming Linux, edit project properties on windows.
Note the "+" was removed from the compute_50 line.


You can also run 9xx cards with only compute_50 but presumably at lower performance.

My 970 has 2x6 pin PCIe connections which is the same as 1x8 which is enough for the rated power
with headroom for OCing. Some 980s (165W) have only 2x6. That shouldn't cause problems for the
connectors unless they are defective. The only real benefit I see with connector overkill is offloading
the PCIe bus, a good idea in multi GPU rigs.

As far as areas of delivery there are only 2, the bus on one corner of the card, and the connector cluster
at the opposite corner. Adding pins to the connector cluster doesn't create more areas of delivery, it
only increases the capacity of the cluster area. Adding more areas requires power connectors at different
locations on the card, but that would complicate cable management and airflow.

Anyway it looks like your problem is fixed and I don't expect your connectors to melt, but don't sue me.

The card is rated at 145W, the 8 pin can handle 150 plus 75 from the slot. I don't think the problem is the
connectors. I'm also not sure about an over-volt fault. If the card is drawing too much power it would
cause a volatge drop. An over-volt might be the PSU or the mains. If you're confident about the power
send the card back.

It really depends on price and whether the price premium for the 980ti is a good tradeoff
for the increased density. I don't have CAD pricing for the 980ti but the 980 has
a higher cost/hash than the 750ti, 960 & 970.

 I expect power efficiency to be comaparable to the rest of the
9xx family