CCminer(SP-MOD) Modded GPU kernels.

[t-nelson]

Is VTC solo issue fixed ?

VTC-SOLO--

T-nelson was working on it when a "Lyra2v2 doesn't work" false alarm propagated thru the thread.  He is diagnosing with one 750ti, so it may take a week to hit a block and get error log and debug info.  CryptoMining Blog states that CCminer crashes on hitting a block, and my personal results agree.  However, I was not running any error-catching software.       --scryptr

I went ahead and tossed the 960 on it as well.  It's been up since sp_ committed the lyra2v2 fix, but no solved blocks yet.  Taking this long to reproduce, I hope to hell it's as dead obvious as the whirlpoolx segv I fixed last week...

[sp_]

beer for you
sp     : e5765c44e2589c7f66c0afcc871a001a35045b03d4b7b9b628f01b9e55720ed4
pallas : 50c053b2871b0fa1856b3dd6465001e28fd6378844f4eccc0a69aca6dc223ad4

Thanks

[sp_]

Does anyone know what the whirlpoolx algo is like on ccminer?

On AMD my whirlpoolx miner does 670 Mh/s.
I tried ccminer some time ago on 970 and it was about 300 Mh/s, if I recall correctly.
I'd be glad to optimize ccminer like I did for AMD, but I see less and less interest in mining that algo, so I dropped the idea.

The whirlpoolx kernal is pretty fast already on the maxwell. But if you can make it faster, the same teqniques might be possible in x11 as well.

The 750ti does around 75MHASH. the 970 around 230MHASH

[sp_]

Is VTC solo issue fixed ?

VTC-SOLO--
T-nelson was working on it when a "Lyra2v2 doesn't work" false alarm propagated thru the thread.  He is diagnosing with one 750ti, so it may take a week to hit a block and get error log and debug info.  CryptoMining Blog states that CCminer crashes on hitting a block, and my personal results agree.  However, I was not running any error-catching software.       --scryptr

I went ahead and tossed the 960 on it as well.  It's been up since sp_ committed the lyra2v2 fix, but no solved blocks yet.  Taking this long to reproduce, I hope to hell it's as dead obvious as the whirlpoolx segv I fixed last week...

try a smaller coin. Zoomcoin? lyra2v2 faster blocks.

[djm34]

Agree, Ethminer is still very lucrative although it looks like Nvidia hardware hit the memory controller limitation and can't go anywhere else, much like Cryptonote.

Look at lyra2v2. It's also a memory hard algorithm.
280x Sgminer opensource(200watt) 4MHASH
750ti Djm-34 (sp-mod) opensource (40watt) 5MHASH
It's like creating a etherum miner that does 35MHASH on the 750ti.
But the opensource is only doing 8MHASH...

(djm34 here...)
The main difference between the algo of ethereum and other mem hard algo, is that you can't rescale mem usage as it always requires the full dag file to run (ie 1.2Gb or so of vram with many random over the full dag file)
Meaning you can't really improve passed what has already been done... (yeah, I tried already   ).

But you should be able to make the kernal run at copyspeed. (memory bandwidth limit) The gpu can do register operations while writing to memory. The keccak passes should be integrated and more than one hash per run. Then you will get keccak for free. (memory pipelining)

not sure to understand what you mean in the context, there are only 2 keccak rounds, 1 before and 1 after the sequence of random access to the dag file. So in my opinion it is already running (mostly) at mem access speed...
(it is easy to check, actually, just need to remove the 2 keccaks loops and see how much you would get).

actually it could be interesting to use the dag file only over a certain range of mem value, and for the remainder recalculate the missing dag item (but the calculation is rather heavy, so it isn't obvious it would work.)

regarding the advance of ccminer over sgminer this is probably only temporary, Wolf0 has a much faster code which is getting pretty much the same speed as my private kernel (so it can be achieved...)

[t-nelson]

Is VTC solo issue fixed ?

VTC-SOLO--
T-nelson was working on it when a "Lyra2v2 doesn't work" false alarm propagated thru the thread.  He is diagnosing with one 750ti, so it may take a week to hit a block and get error log and debug info.  CryptoMining Blog states that CCminer crashes on hitting a block, and my personal results agree.  However, I was not running any error-catching software.       --scryptr

I went ahead and tossed the 960 on it as well.  It's been up since sp_ committed the lyra2v2 fix, but no solved blocks yet.  Taking this long to reproduce, I hope to hell it's as dead obvious as the whirlpoolx segv I fixed last week...

try a smaller coin. Zoomcoin? lyra2v2 faster blocks.

I have my doubts it's actually a Lyra2v2 problem.  It would crash outright in that case, not after finding a block.  More likely it's some issue communicating with the VTC wallet.

[impulse2000]

How launch with ScryptNf??

Code:

ccminer.exe -a scrypt:4096 -o stratum+tcp://scryptnf.eu.nicehash.com:3335 -u 18EJ9w1MuZXWDNNEuLAyq4SJJUsYx9fqiX -p x -l T5x12 -C -D
*** ccminer 1.5.68-git(SP-MOD) for nVidia GPUs by sp-hash@github ***
        Built with VC++ 2013 and nVidia CUDA SDK 6.5

  Based on pooler cpuminer 2.3.2 and the tpruvot@github fork
  CUDA support by Christian Buchner, Christian H. and DJM34
  Includes optimizations implemented by sp, klaust, tpruvot, tsiv and pallas.

[2015-09-18 20:47:07] Cpu mining enabled...
[2015-09-18 20:47:07] tid(0x00000750) Starting Stratum on stratum+tcp://scryptnf.eu.nicehash.com:3335
[2015-09-18 20:47:07] tid(0x00000750) restart_threads
[2015-09-18 20:47:07] tid(0x0000098c) CUDA GPU#0 matches NVAPI GPU 0 by busId 1
[2015-09-18 20:47:07] tid(0x0000098c) NVAPI GPU monitoring enabled.
[2015-09-18 20:47:07] tid(0x0000098c) 1 miner thread started, using 'scrypt' algorithm.
[2015-09-18 20:47:07] tid(0x00000ce8) Binding thread 0 to cpu 0 (mask 1)
[2015-09-18 20:47:08] tid(0x00000750) Stratum difficulty set to 256
[2015-09-18 20:47:08] tid(0x00000750) stratum time is at least 7205s in the future
[2015-09-18 20:47:08] tid(0x00000750) DEBUG: job_id=5fc5c31 000000047d480142 xnonce2=000000 time=20:47:08
[2015-09-18 20:47:08] tid(0x00000750) scryptnf.eu.nicehash.com:3335 scrypt block 636800
[2015-09-18 20:47:08] tid(0x00000750) restart_threads
[2015-09-18 20:47:08] tid(0x00000ce8) sleeptime: 500 ms
[2015-09-18 20:47:08] tid(0x00000ce8) job 5fc5c31 000000047d480142 target change: ffff000000 (1.0)
[2015-09-18 20:47:08] tid(0x00000ce8) GPU #0: start=00000000 end=000fffff range=000fffff
[2015-09-18 20:47:08] tid(0x00000ce8) GPU #0: GeForce GTX 750 Ti with SM 5.0
[2015-09-18 20:47:08] tid(0x00000ce8) GPU #0: interactive: 0, tex-cache: 0, single-alloc: 0
[2015-09-18 20:47:08] tid(0x00000ce8) GPU #0: 32 hashes / 0.0 MB per warp.
[2015-09-18 20:47:08] tid(0x00000ce8) GPU #0: using launch configuration T5x12
[2015-09-18 20:47:08] tid(0x00000ce8) scrypt factor set to 4096 (2)
[2015-09-18 20:47:50] tid(0x00000750) stratum time is at least 7218s in the future
[2015-09-18 20:47:50] tid(0x00000750) DEBUG: job_id=5fc5c68 000000047d48014b xnonce2=000000 time=20:47:50
[2015-09-18 20:47:50] tid(0x00000750) scryptnf.eu.nicehash.com:3335 asks job -1 for block 636800

[bathrobehero]

I would advise setting up each rig as it's own nicehash worker, and preferably use fixed share difficulty, adjusted to about 1 share per minute on each rig (needs experimentation until the best value is found).

Why would you want such low sharerate? With 1 share/minute you're going to have tons of blocks for which you're not going to contribute any shares in time.
Especially with low block target coins like Sharkcoin with 20 second target, so you will only contribute one huge share for every 3rd block and for the rest, your work is just going to get locally discarded because there's a new block the miner has to start working on from scratch. Even though you're probably going to get paid as if you had submitted shares for every blocks  (depending on the pool's settings) but the discraded work has to decrease the pool's overall efficiency. If it's not the case, what am I missing?

[pallas]

Does anyone know what the whirlpoolx algo is like on ccminer?

On AMD my whirlpoolx miner does 670 Mh/s.
I tried ccminer some time ago on 970 and it was about 300 Mh/s, if I recall correctly.
I'd be glad to optimize ccminer like I did for AMD, but I see less and less interest in mining that algo, so I dropped the idea.

The whirlpoolx kernal is pretty fast already on the maxwell. But if you can make it faster, the same teqniques might be possible in x11 as well.

The 750ti does around 75MHASH. the 970 around 230MHASH

Whirlpoolx is almost unique in how it was conceived: it really looks like it was made to favourite smart developers.
The large part of the optimisations come from "shortcuts", more than general algorithm speedup. In the end it's just reiterated whirlpool (which in turn is similar to groestl and other aes derived algos).
So I guess that a 970 with all the "shortcuts" in place, should be about as good as a 280x (500 Mh/s).

[flipclip]

How launch with ScryptNf??

Code:

ccminer.exe -a scrypt:4096 -o stratum+tcp://scryptnf.eu.nicehash.com:3335 -u 18EJ9w1MuZXWDNNEuLAyq4SJJUsYx9fqiX -p x -l T5x12 -C -D

I thought for 4096 iterations it needed to be set to scrypt:20 , but I haven't used scryptn in a while.

[myagui]

I would advise setting up each rig as it's own nicehash worker, and preferably use fixed share difficulty, adjusted to about 1 share per minute on each rig (needs experimentation until the best value is found).

Why would you want such low sharerate? With 1 share/minute you're going to have tons of blocks for which you're not going to contribute any shares in time.
Especially with low block target coins like Sharkcoin with 20 second target, so you will only contribute one huge share for every 3rd block and for the rest, your work is just going to get locally discarded because there's a new block the miner has to start working on from scratch. Even though you're probably going to get paid as if you had submitted shares for every blocks  (depending on the pool's settings) but the discraded work has to decrease the pool's overall efficiency. If it's not the case, what am I missing?

As someone else corrected already, it is just the starting diff, so the only use on Nicehash is to prevent the slow difficulty "ramp-up" time when you 1st get connected.

Personally, I tend to aim towards high'ish share difficulty also on pools that allow a fixed/permanent setting, as over time, I've built the impression that pools are not linearly increasing share-count with share-diff. Which makes sense really.
A miner sending a gazillion low diff shares takes up a lot more pool resources, than a miner with identical hashrate but sending just a few high diff shares. In any case, I'm not sure it matters much.

[bathrobehero]

I would advise setting up each rig as it's own nicehash worker, and preferably use fixed share difficulty, adjusted to about 1 share per minute on each rig (needs experimentation until the best value is found).

Why would you want such low sharerate? With 1 share/minute you're going to have tons of blocks for which you're not going to contribute any shares in time.
Especially with low block target coins like Sharkcoin with 20 second target, so you will only contribute one huge share for every 3rd block and for the rest, your work is just going to get locally discarded because there's a new block the miner has to start working on from scratch. Even though you're probably going to get paid as if you had submitted shares for every blocks  (depending on the pool's settings) but the discraded work has to decrease the pool's overall efficiency. If it's not the case, what am I missing?

As someone else corrected already, it is just the starting diff, so the only use on Nicehash is to prevent the slow difficulty "ramp-up" time when you 1st get connected.

Personally, I tend to aim towards high'ish share difficulty also on pools that allow a fixed/permanent setting, as over time, I've built the impression that pools are not linearly increasing share-count with share-diff. Which makes sense really.
A miner sending a gazillion low diff shares takes up a lot more pool resources, than a miner with identical hashrate but sending just a few high diff shares. In any case, I'm not sure it matters much.

Talking about fixed diff only (as vardiff has other issues) and not just spamming the pool with tiny shares (>1 share/sec), the goal should be to avoid working on shares that take too long to submit before a new block is introduced on the network because in that case the work is being discarded and the miner starts to work on the next block from scratch. I think it matters a lot and in case of a slow sharerate you're going to see a very spiky hashrate graph with probably lower payouts and worse overall pool efficiency. Again, unless I miss something.

[myagui]

I'm referring to how some pools weight share value (or share count), in a non-linear relationship to share difficulty. An average of 1 minute per share is not really a spiky graphic, unless you're zooming in on some 5 minute window  
When you run into a pool that allows fixed/permanent difficulty, really, try it out. See how the graph looks for a few hours on auto difficulty, versus a fixed higher difficulty (but not too high). Yaamp was one pool where I noticed this, when it was around...

Sidenote: I do have decent (small) latency to any/all of the pools I use. For people with bad connections and high latency, high share difficulty will also increase the rejection rate (invalid work, submitted too late).

Edit: There's also the advantage that with fixed diff, you don't get as many job restarts due to the constant difficulty adjustments. It could well be that I was seeing this benefit (of fixed diff vs variable diff), as opposed to a benefit of higher diff shares per se. I'll post some comparative results when I'm at a pool that allows me to mess around with both methods.

[sp_]

Whirlpoolx is almost unique in how it was conceived: it really looks like it was made to favourite smart developers.
The large part of the optimisations come from "shortcuts", more than general algorithm speedup. In the end it's just reiterated whirlpool (which in turn is similar to groestl and other aes derived algos).
So I guess that a 970 with all the "shortcuts" in place, should be about as good as a 280x (500 Mh/s).

Thats why x11 is safer. Supported by Daesh..
I wonder why the poor NVIDIA miners are skipping the ETHER algo... Such Profit loss

[antonio8]

Whirlpoolx is almost unique in how it was conceived: it really looks like it was made to favourite smart developers.
The large part of the optimisations come from "shortcuts", more than general algorithm speedup. In the end it's just reiterated whirlpool (which in turn is similar to groestl and other aes derived algos).
So I guess that a 970 with all the "shortcuts" in place, should be about as good as a 280x (500 Mh/s).

Thats why x11 is safer. Supported by Daesh..
I wonder why the poor NVIDIA miners are skipping the ETHER algo... Such Profit loss

Right now AMD does a lot better on hashing. At least Nvidia does better on Linux than Windows. Unfortunately I am on Windows.

[pallas]

Talking about fixed diff only (as vardiff has other issues) and not just spamming the pool with tiny shares (>1 share/sec), the goal should be to avoid working on shares that take too long to submit before a new block is introduced on the network because in that case the work is being discarded and the miner starts to work on the next block from scratch. I think it matters a lot and in case of a slow sharerate you're going to see a very spiky hashrate graph with probably lower payouts and worse overall pool efficiency. Again, unless I miss something.

"Time to submit a share" doesn't depend on diff.
Nor does time to compute. Higher diff just means "less likely to find a share but with more value", so statistically speaking there is no disadvantage in higher diff.

[bcmog]

asus strix gtx750ti @ 1402/5202
quark, default settings
R67 12h@nicehash 6.83mh / zero rejects
R68 12h@nicehash 6.79mh / 0.18mh rejects

Try 12 hours with the parameter -i 22.9

R68 -i 22.9 12h@nicehash 6.98mh / nearly zero rejects

thanks!!

[Vita1ico]

ccminer.exe -C -q -a quark -o stratum+tcp://quark.eu.nicehash.com:3345 -u 1MNsjDhAeubHqftyUiDnmUudiGkJcVsBmX -p x

what else want to add that there is less rejects ?

[Cryptozillah]

Updated to r68 and lowered intensity to 22.9

[pallas]

I've sent pull requests with code which prints additional nvml info (graphics clock and memory clock).
It's useful to detect throttling, among other things.
I'm not sure it works on all cards, I only have 970s, please test.