t-nelson
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 70
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 05:46:46 PM |
|
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
Activity: 2926
Merit: 1087
Team Black developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 05:51:43 PM |
|
beer for you sp : e5765c44e2589c7f66c0afcc871a001a35045b03d4b7b9b628f01b9e55720ed4 pallas : 50c053b2871b0fa1856b3dd6465001e28fd6378844f4eccc0a69aca6dc223ad4
Thanks ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2926
Merit: 1087
Team Black developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 05:53:07 PM |
|
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_ (OP)
Legendary
Offline
Activity: 2926
Merit: 1087
Team Black developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 05:58:20 PM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1050
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 05:58:28 PM |
|
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](https://bitcointalk.org/Smileys/default/grin.gif) ). 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 pageBTC: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze Pledge for neoscrypt ccminer to that address: 16UoC4DmTz2pvhFvcfTQrzkPTrXkWijzXw
|
|
|
t-nelson
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 70
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 06:19:14 PM |
|
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
Activity: 26
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 06:30:14 PM Last edit: September 18, 2015, 06:49:48 PM by impulse2000 |
|
How launch with ScryptNf?? 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
Activity: 2002
Merit: 1051
ICO? Not even once.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 07:18:39 PM |
|
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
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 07:50:30 PM |
|
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
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 111
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 08:24:38 PM |
|
How launch with ScryptNf?? 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
Activity: 1154
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 08:48:49 PM |
|
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
Activity: 2002
Merit: 1051
ICO? Not even once.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 09:49:43 PM |
|
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
Activity: 1154
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 09:59:47 PM Last edit: September 18, 2015, 10:20:52 PM by 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Activity: 2926
Merit: 1087
Team Black developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2015, 01:47:39 AM |
|
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
Legendary
Offline
Activity: 1400
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2015, 01:55:23 AM |
|
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](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2015, 07:30:50 AM |
|
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
Activity: 7
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2015, 08:39:13 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2015, 09:51:54 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2015, 12:00:02 PM |
|
Updated to r68 and lowered intensity to 22.9 ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fi62.tinypic.com%2F28gyoty.png&t=665&c=NmqTwAB2ty3cqQ)
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 19, 2015, 12:27:16 PM |
|
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.
|
|
|
|
|