CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 938.

myagui

legendary

Activity: 1154

Merit: 1001

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.

bathrobehero

legendary

Activity: 2002

Merit: 1051

ICO? Not even once.

Quote from: myagui on September 18, 2015, 03:48:49 PM

Quote from: bathrobehero on September 18, 2015, 02:18:39 PM

Quote from: myagui on September 18, 2015, 09:14:29 AM

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

legendary

Activity: 1154

Merit: 1001

Quote from: bathrobehero on September 18, 2015, 02:18:39 PM

Quote from: myagui on September 18, 2015, 09:14:29 AM

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.

flipclip

member

Activity: 111

Merit: 10

Quote from: impulse2000 on September 18, 2015, 01:30:14 PM

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.

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

Quote from: sp_ on September 18, 2015, 12:53:07 PM

Quote from: pallas on September 18, 2015, 10:39:14 AM

Quote from: pokeytex on September 18, 2015, 10:36:04 AM

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).

bathrobehero

legendary

Activity: 2002

Merit: 1051

ICO? Not even once.

Quote from: myagui on September 18, 2015, 09:14:29 AM

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?

impulse2000

newbie

Activity: 26

Merit: 0

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

t-nelson

member

Activity: 70

Merit: 10

Quote from: sp_ on September 18, 2015, 12:58:20 PM

Quote from: t-nelson on September 18, 2015, 12:46:46 PM

Quote from: scryptr on September 18, 2015, 08:03:57 AM

Quote from: qqqq on September 18, 2015, 07:32:34 AM

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.

djm34

legendary

Activity: 1400

Merit: 1050

Quote from: sp_ on September 18, 2015, 06:51:06 AM

Quote from: theotherme on September 18, 2015, 05:56:09 AM

Quote from: sp_ on September 18, 2015, 04:28:52 AM

Quote from: bensam1231 on September 18, 2015, 02:58:20 AM

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 Grin

).

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...)

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: t-nelson on September 18, 2015, 12:46:46 PM

Quote from: scryptr on September 18, 2015, 08:03:57 AM

Quote from: qqqq on September 18, 2015, 07:32:34 AM

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.

sp_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: pallas on September 18, 2015, 10:39:14 AM

Quote from: pokeytex on September 18, 2015, 10:36:04 AM

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_

legendary

Activity: 2954

Merit: 1087

Team Black developer

Quote from: Masked_Immortal on September 18, 2015, 09:04:03 AM

beer for you
sp : e5765c44e2589c7f66c0afcc871a001a35045b03d4b7b9b628f01b9e55720ed4
pallas : 50c053b2871b0fa1856b3dd6465001e28fd6378844f4eccc0a69aca6dc223ad4

Thanks

t-nelson

member

Activity: 70

Merit: 10

Quote from: scryptr on September 18, 2015, 08:03:57 AM

Quote from: qqqq on September 18, 2015, 07:32:34 AM

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...

Cryptozillah

hero member

Activity: 687

Merit: 502

Quote from: flipclip on September 18, 2015, 11:27:48 AM

Quote from: myagui on September 18, 2015, 11:11:43 AM

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

Its starting diff, and set as your preferred difficulty (though if there are no orders at that diff, nicehash adjusts it)
From Nicehash: "Nevertheless you can use parameter d=diff in your password to set starting difficulty." and "...since the difficultly you set is only a preferred difficulty and the actual difficulty depends on the current orders at NiceHash."

Good stuff ! Thanks alot

Quote from: flipclip on September 18, 2015, 11:31:35 AM

Quote from: Cryptozillah on September 18, 2015, 11:18:58 AM

....
I will give it some time to try out stuff with individial workers.

For the worker name nicehash accepts "up to seven alphanumeric (Aa-Zz, 0-9) characters". Just in case you get too crazy with the name Wink

ok, miner 1-6 works for me lol

flipclip

member

Activity: 111

Merit: 10

Quote from: Cryptozillah on September 18, 2015, 11:18:58 AM

....
I will give it some time to try out stuff with individial workers.

For the worker name nicehash accepts "up to seven alphanumeric (Aa-Zz, 0-9) characters". Just in case you get too crazy with the name Wink

flipclip

member

Activity: 111

Merit: 10

Quote from: myagui on September 18, 2015, 11:11:43 AM

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

Its starting diff, and set as your preferred difficulty (though if there are no orders at that diff, nicehash adjusts it)
From Nicehash: "Nevertheless you can use parameter d=diff in your password to set starting difficulty." and "...since the difficultly you set is only a preferred difficulty and the actual difficulty depends on the current orders at NiceHash."

Cryptozillah

hero member

Activity: 687

Merit: 502

Quote from: myagui on September 18, 2015, 11:11:43 AM

Quote from: Cryptozillah on September 18, 2015, 10:32:19 AM

[...]
I am running 24 right now on my nvidia rigs. I will lower it a bit and see what happends.
I have the same problems on my AMD rigs though. I forgot to say that.
[...]
How do i do that ?, i mean set fixed share diff ?
I need a full reboot to gain maximum accepted hashrate at NiceHash. Restarting the miner only wont affect anything.

You didn't say anything about running separate workers. I don't understand how you can tell that the problem is global, without having looked at individual worker stats. This is particularly important since you mention that also AMD rigs are doing the same.

It's most likely that it is a single rig having trouble, not all of them.

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

For individual worker shares, all mining into the same BTC addy:
-u yourbtcaddy.worker (replace worker with some unique worker name for each rig)

Another way of finding out which rig is causing trouble, if it is indeed a single rig, is that you could point one rig at a time into some alternate btc addy, so that you isolate the stats for that rig alone. Measure up to the 2 hour point or so, and move on to the next rig. With individual worker names you should be able to monitor individual rig stats while keeping the btc destination the same.

Ah i see. I just thought it was too much hashrate to only involve one of my rigs.
Thanks for the explanation about the diff. I will give it some time to try out stuff with individial workers.

myagui

legendary

Activity: 1154

Merit: 1001

Quote from: Cryptozillah on September 18, 2015, 10:32:19 AM

[...]
I am running 24 right now on my nvidia rigs. I will lower it a bit and see what happends.
I have the same problems on my AMD rigs though. I forgot to say that.
[...]
How do i do that ?, i mean set fixed share diff ?
I need a full reboot to gain maximum accepted hashrate at NiceHash. Restarting the miner only wont affect anything.

You didn't say anything about running separate workers. I don't understand how you can tell that the problem is global, without having looked at individual worker stats. This is particularly important since you mention that also AMD rigs are doing the same.

It's most likely that it is a single rig having trouble, not all of them.

For fixed difficulty (though I'm not sure if it stays fixed onwards, or if just adjusting starting diff):
-p d=1 (replace 1 with whatever is your desired difficulty)

For individual worker shares, all mining into the same BTC addy:
-u yourbtcaddy.worker (replace worker with some unique worker name for each rig)

Another way of finding out which rig is causing trouble, if it is indeed a single rig, is that you could point one rig at a time into some alternate btc addy, so that you isolate the stats for that rig alone. Measure up to the 2 hour point or so, and move on to the next rig. With individual worker names you should be able to monitor individual rig stats while keeping the btc destination the same.

flipclip

member

Activity: 111

Merit: 10

Quote from: scryptr on September 18, 2015, 11:00:21 AM

Quote from: chrysophylax on September 18, 2015, 08:28:31 AM

Quote from: scryptr on September 18, 2015, 08:03:57 AM

Quote from: qqqq on September 18, 2015, 07:32:34 AM

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

false alarm? ... what did i miss? ...

#crysx

MEMORY--

I beleive that you said that you were using the wrong port. --scryptr

He might have been, but lyra2v2 was broken, which sp_ fixed.

scryptr

legendary

Activity: 1797

Merit: 1028

Quote from: chrysophylax on September 18, 2015, 08:28:31 AM

Quote from: scryptr on September 18, 2015, 08:03:57 AM

Quote from: qqqq on September 18, 2015, 07:32:34 AM

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

false alarm? ... what did i miss? ...

#crysx

MEMORY--

I beleive that you said that you were using the wrong port. --scryptr

Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 938. (Read 2347664 times)