Bitcoin Forum
June 17, 2024, 01:52:00 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: « 1 ... 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 [304] 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 ... 1240 »
  Print  
Author Topic: CCminer(SP-MOD) Modded GPU kernels.  (Read 2347501 times)
t-nelson
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
September 18, 2015, 05:46:46 PM
 #6061

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

BTC:   1K4yxRwZB8DpFfCgeJnFinSqeU23dQFEMu
DASH: XcRSCstQpLn8rgEyS6yH4Kcma4PfcGSJxe
sp_ (OP)
Legendary
*
Offline Offline

Activity: 2912
Merit: 1087

Team Black developer


View Profile
September 18, 2015, 05:51:43 PM
 #6062

beer for you
sp     : e5765c44e2589c7f66c0afcc871a001a35045b03d4b7b9b628f01b9e55720ed4
pallas : 50c053b2871b0fa1856b3dd6465001e28fd6378844f4eccc0a69aca6dc223ad4

Thanks Smiley

Team Black Miner (ETHB3 ETH ETC VTC KAWPOW FIROPOW MEOWPOW + dual mining + tripple mining.. https://github.com/sp-hash/TeamBlackMiner
sp_ (OP)
Legendary
*
Offline Offline

Activity: 2912
Merit: 1087

Team Black developer


View Profile
September 18, 2015, 05:53:07 PM
 #6063

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

Team Black Miner (ETHB3 ETH ETC VTC KAWPOW FIROPOW MEOWPOW + dual mining + tripple mining.. https://github.com/sp-hash/TeamBlackMiner
sp_ (OP)
Legendary
*
Offline Offline

Activity: 2912
Merit: 1087

Team Black developer


View Profile
September 18, 2015, 05:58:20 PM
 #6064

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.

Team Black Miner (ETHB3 ETH ETC VTC KAWPOW FIROPOW MEOWPOW + dual mining + tripple mining.. https://github.com/sp-hash/TeamBlackMiner
djm34
Legendary
*
Offline Offline

Activity: 1400
Merit: 1050


View Profile WWW
September 18, 2015, 05:58:28 PM
 #6065

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

djm34 facebook page
BTC: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze
Pledge for neoscrypt ccminer to that address: 16UoC4DmTz2pvhFvcfTQrzkPTrXkWijzXw
t-nelson
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
September 18, 2015, 06:19:14 PM
 #6066

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.

BTC:   1K4yxRwZB8DpFfCgeJnFinSqeU23dQFEMu
DASH: XcRSCstQpLn8rgEyS6yH4Kcma4PfcGSJxe
impulse2000
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
September 18, 2015, 06:30:14 PM
Last edit: September 18, 2015, 06:49:48 PM by impulse2000
 #6067

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
Legendary
*
Offline Offline

Activity: 2002
Merit: 1051


ICO? Not even once.


View Profile
September 18, 2015, 07:18:39 PM
 #6068

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?

Not your keys, not your coins!
pallas
Legendary
*
Offline Offline

Activity: 2716
Merit: 1094


Black Belt Developer


View Profile
September 18, 2015, 07:50:30 PM
 #6069

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
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
September 18, 2015, 08:24:38 PM
 #6070

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
Legendary
*
Offline Offline

Activity: 1154
Merit: 1001



View Profile
September 18, 2015, 08:48:49 PM
 #6071

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
Legendary
*
Offline Offline

Activity: 2002
Merit: 1051


ICO? Not even once.


View Profile
September 18, 2015, 09:49:43 PM
 #6072

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.

Not your keys, not your coins!
myagui
Legendary
*
Offline Offline

Activity: 1154
Merit: 1001



View Profile
September 18, 2015, 09:59:47 PM
Last edit: September 18, 2015, 10:20:52 PM by myagui
 #6073

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  Smiley
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_ (OP)
Legendary
*
Offline Offline

Activity: 2912
Merit: 1087

Team Black developer


View Profile
September 19, 2015, 01:47:39 AM
 #6074

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




Team Black Miner (ETHB3 ETH ETC VTC KAWPOW FIROPOW MEOWPOW + dual mining + tripple mining.. https://github.com/sp-hash/TeamBlackMiner
antonio8
Legendary
*
Offline Offline

Activity: 1386
Merit: 1000


View Profile
September 19, 2015, 01:55:23 AM
 #6075

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.

If you are going to leave your BTC on an exchange please send it to this address instead 1GH3ub3UUHbU5qDJW5u3E9jZ96ZEmzaXtG, I will at least use the money better than someone who steals it from the exchange. Thanks Wink
pallas
Legendary
*
Offline Offline

Activity: 2716
Merit: 1094


Black Belt Developer


View Profile
September 19, 2015, 07:30:50 AM
 #6076

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
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
September 19, 2015, 08:39:13 AM
 #6077

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
Full Member
***
Offline Offline

Activity: 155
Merit: 100


View Profile
September 19, 2015, 09:51:54 AM
 #6078

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
Hero Member
*****
Offline Offline

Activity: 687
Merit: 502


View Profile
September 19, 2015, 12:00:02 PM
 #6079

Updated to r68 and lowered intensity to 22.9
pallas
Legendary
*
Offline Offline

Activity: 2716
Merit: 1094


Black Belt Developer


View Profile
September 19, 2015, 12:27:16 PM
 #6080

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.

Pages: « 1 ... 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 [304] 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 ... 1240 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!