I am looking at the Etherum miner now. I have some improvements.
Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 874. (Read 2347659 times)
Thanks
I am looking at the Etherum miner now. I have some improvements.
I am looking at the Etherum miner now. I have some improvements.
hashpower payed good, because they mined mobilecash (lyra2v2)
https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
last I checked give me coins had 62% of hash for Vert, for a coin that's main value proposition is decentralization by avoiding asics and devs making setting up p2pool super easy that's pathetic to have all the hash on one pool. GMC doesn't even merge mine MBL...crypto confuses me sometimes.
Zoomcoin (lyra2v2) is looking good now.
I just sold my verts to put half a bitcoin into that voxelus tokensale, I don't care about the coin just interested cause it's backed by legit people not a scam and quick turnaround, sale lasts 30 days and then coins are released so hoping I can dump for a quick profit in 30 days.
Only reason I'm telling you I liquidated my VTC is because I'm sending a donation..but it's only 31 VTC lol, the ones mined since I dumped to invest in the crowdsale. Also if anyone reads this and invests in voxelus, the first day ends in a few hours and after that you get 10% less coins. No idea if it will be profitable, ETH only crowdsale I've done. If it loses BTC don't blame me
Just seemed more interesting than holding VTC 
hashpower payed good, because they mined mobilecash (lyra2v2)
https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
last I checked give me coins had 62% of hash for Vert, for a coin that's main value proposition is decentralization by avoiding asics and devs making setting up p2pool super easy that's pathetic to have all the hash on one pool. GMC doesn't even merge mine MBL...crypto confuses me sometimes.
Zoomcoin (lyra2v2) is looking good now.
I made some changes about that but i dont recommend it... Like 2 miners are generally not faster than one, but indeed for this special case, that could be a workaround ( 2 miner instances = 2 connections)
-d 0,0 To try
-d 0,0 To try
In my fork you can use -g 2, -g 3 or -g 4 just like in sgminer.
But the maximum threadscount should be less than 32. So for a 6 gpu rig -g 5 is the max value..
in fact in -d 0,0 is not the best way on mine, i made something special with -d 0 -t 2 or just -t 4 with 2 devices. But most algos seems to make validation errors after some time, i dont really understand the reason.
Code:
2015-11-03 12:48:12] accepted: 78/78 (diff 0.040), 210.14 MH/s yes!
[2015-11-03 12:48:12] GPU T3: ASUS GTX 960, 50.92 MH/s
[2015-11-03 12:48:12] GPU T0: MSI GTX 960, 53.17 MH/s
[2015-11-03 12:48:12] accepted: 79/79 (diff 0.032), 210.06 MH/s yes!
[2015-11-03 12:48:12] accepted: 80/80 (diff 0.032), 210.06 MH/s yes!
[2015-11-03 12:48:12] GPU T2: MSI GTX 960, 52.87 MH/s
[2015-11-03 12:48:12] GPU T0: MSI GTX 960, 51.16 MH/s
[2015-11-03 12:48:12] accepted: 81/81 (diff 0.006), 209.97 MH/s yes!
[2015-11-03 12:48:12] accepted: 82/82 (diff 0.006), 209.97 MH/s yes!
[2015-11-03 12:48:12] GPU T3: ASUS GTX 960, 53.18 MH/s
[2015-11-03 12:48:12] GPU T3: ASUS GTX 960, 50.92 MH/s
[2015-11-03 12:48:12] GPU T0: MSI GTX 960, 53.17 MH/s
[2015-11-03 12:48:12] accepted: 79/79 (diff 0.032), 210.06 MH/s yes!
[2015-11-03 12:48:12] accepted: 80/80 (diff 0.032), 210.06 MH/s yes!
[2015-11-03 12:48:12] GPU T2: MSI GTX 960, 52.87 MH/s
[2015-11-03 12:48:12] GPU T0: MSI GTX 960, 51.16 MH/s
[2015-11-03 12:48:12] accepted: 81/81 (diff 0.006), 209.97 MH/s yes!
[2015-11-03 12:48:12] accepted: 82/82 (diff 0.006), 209.97 MH/s yes!
[2015-11-03 12:48:12] GPU T3: ASUS GTX 960, 53.18 MH/s
hashpower payed good, because they mined mobilecash (lyra2v2)
https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
last I checked give me coins had 62% of hash for Vert, for a coin that's main value proposition is decentralization by avoiding asics and devs making setting up p2pool super easy that's pathetic to have all the hash on one pool. GMC doesn't even merge mine MBL...crypto confuses me sometimes.
This problem appears on really fast algos. I made the dup check for this reason when i wrote the blake algo.
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
You need to work on your marketing.
Sell it as, "saving power when the network has no work available," or something.The biggest mistake a FLOSS developer can make is letting users drive development.
Do what's right and ignore the uninformed, baseless complaints.
And that includes me as a user. Users are just good for feedback on performance, testing, ect. it's usually those that are the most ignorant that are the loudest in their comments/complaints. Ignore them, and if a user asks politely why the gpu isn't 100% just give a simple explanation. If they complain tell them to STFU or fix it themselves.
Just my 2 satoshi
hashpower payed good, because they mined mobilecash (lyra2v2)
https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
https://bitcointalksearch.org/topic/mobilecash-first-poch-coin-proof-of-charity-1182734
OFF: hashpower and ffpool down again...
I made some changes about that but i dont recommend it... Like 2 miners are generally not faster than one, but indeed for this special case, that could be a workaround ( 2 miner instances = 2 connections)
-d 0,0 To try
-d 0,0 To try
In my fork you can use -g 2, -g 3 or -g 4 just like in sgminer.
But the maximum threadscount should be less than 32. So for a 6 gpu rig -g 5 is the max value..
I made some changes about that but i dont recommend it... Like 2 miners are generally not faster than one, but indeed for this special case, that could be a workaround ( 2 miner instances = 2 connections)
-d 0,0 To try
-d 0,0 To try
This problem appears on really fast algos. I made the dup check for this reason when i wrote the blake algo.
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
You need to work on your marketing.
Sell it as, "saving power when the network has no work available," or something.The biggest mistake a FLOSS developer can make is letting users drive development. 99% of users don't have the skills, experience or insight to make development decisions. This is a prime example of why. Of course it is ideal to keep the GPUs pegged at 100% usage. But if there is nothing productive to do, then there is zero sense in burning the watts.
Do what's right and ignore the uninformed, baseless complaints.
A major part of optimizing is making productive use of all the available resources. The only knock against
users is the assumption that all the GPU's usage is productive. Users may express their concerns in superficial terms
but it doesn't mean they want a superficial product.
Has anyone tried running 2 GPU threads with the tpruvot fork?
This problem appears on really fast algos. I made the dup check for this reason when i wrote the blake algo.
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
You need to work on your marketing.
Sell it as, "saving power when the network has no work available," or something.The biggest mistake a FLOSS developer can make is letting users drive development. 99% of users don't have the skills, experience or insight to make development decisions. This is a prime example of why. Of course it is ideal to keep the GPUs pegged at 100% usage. But if there is nothing productive to do, then there is zero sense in burning the watts.
Do what's right and ignore the uninformed, baseless complaints.
This problem appears on really fast algos. I made the dup check for this reason when i wrote the blake algo.
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
The full range is scanned before we get a new job from the pool.... Now, what should we do in this case... Wait but users complains about the low GPU usage
I have windows 8.1 and titan x
Now I updated to latest version sp ccminer 1.5.72-git from http://cryptomining-blog.com/6189-updated-windows-binary-of-the-ccminer-1-5-72-git-fork-by-sp-for-maxwell/
And updated my cuda to version 7.5.18
Now the hashrate appears to be bigger but now it says "reject reason: duplicate share" please help
Now I updated to latest version sp ccminer 1.5.72-git from http://cryptomining-blog.com/6189-updated-windows-binary-of-the-ccminer-1-5-72-git-fork-by-sp-for-maxwell/
And updated my cuda to version 7.5.18
Now the hashrate appears to be bigger but now it says "reject reason: duplicate share" please help
Use cuda 6.5. This fork is made for cuda 6.5 and not 7.5.
(But cuda is only needed if you are building yourself) If you run the exe, you just need the latest drivers.
in the ccminer.cpp file, try to move the case ALGO_SKEIN above the minmax = 0x70000000U and recompile.
if (max64 < minmax) {
switch (opt_algo) {
case ALGO_KECCAK:
case ALGO_BLAKECOIN:
case ALGO_BLAKE:
case ALGO_PENTABLAKE:
case ALGO_WHC:
case ALGO_SKEIN:
minmax = 0x70000000U;
break;
case ALGO_BITCOIN:
case ALGO_WHCX:
case ALGO_QUBIT:
case ALGO_QUARK:
case ALGO_LYRA2v2:
minmax = 0x40000000U;
break;
In myr-groestl try to run with --diff 0.00390625
on your latest release72 mining skein on pools gives a lot of rejects, tried different diffs:
http://imgur.com/EiDjINp
i also tried it on tpruvot and it seems to be ok:
http://imgur.com/ofKpcSh
I have windows 8.1 and titan x
Now I updated to latest version sp ccminer 1.5.72-git from http://cryptomining-blog.com/6189-updated-windows-binary-of-the-ccminer-1-5-72-git-fork-by-sp-for-maxwell/
And updated my cuda to version 7.5.18
Now the hashrate appears to be bigger but now it says "reject reason: duplicate share" please help
Now I updated to latest version sp ccminer 1.5.72-git from http://cryptomining-blog.com/6189-updated-windows-binary-of-the-ccminer-1-5-72-git-fork-by-sp-for-maxwell/
And updated my cuda to version 7.5.18
Now the hashrate appears to be bigger but now it says "reject reason: duplicate share" please help
Use cuda 6.5. This fork is made for cuda 6.5 and not 7.5.
(But cuda is only needed if you are building yourself) If you run the exe, you just need the latest drivers.
in the ccminer.cpp file, try to move the case ALGO_SKEIN above the minmax = 0x70000000U and recompile.
if (max64 < minmax) {
switch (opt_algo) {
case ALGO_KECCAK:
case ALGO_BLAKECOIN:
case ALGO_BLAKE:
case ALGO_PENTABLAKE:
case ALGO_WHC:
case ALGO_SKEIN:
minmax = 0x70000000U;
break;
case ALGO_BITCOIN:
case ALGO_WHCX:
case ALGO_QUBIT:
case ALGO_QUARK:
case ALGO_LYRA2v2:
minmax = 0x40000000U;
break;
In myr-groestl try to run with --diff 0.00390625
Hey
I only have 1 graphics card so I let my computer mine digibyte while I am sleeping at night. So when I wake up I can find free coins in my wallet from letting it mine at night
Using the sp ccminer I get 270 mh/s skein.
But using the tpruvot ccminer I get 400 mh/s skein.
That difference of skein hashrate is my only complaint.
The sp miner gives me about 5-10% greater speed when using other algorithms though.
For example I get 9.8 mh/s x13 hashrate in the sp ccminer vs 9.4 mh/s x13 in the tpruvot miner.
62 mh/s myriad-groestl in sp ccminer vs 57 mh/s in the tpruvot ccminer.
I only have 1 graphics card so I let my computer mine digibyte while I am sleeping at night. So when I wake up I can find free coins in my wallet from letting it mine at night
Using the sp ccminer I get 270 mh/s skein.
But using the tpruvot ccminer I get 400 mh/s skein.
That difference of skein hashrate is my only complaint.
The sp miner gives me about 5-10% greater speed when using other algorithms though.
For example I get 9.8 mh/s x13 hashrate in the sp ccminer vs 9.4 mh/s x13 in the tpruvot miner.
62 mh/s myriad-groestl in sp ccminer vs 57 mh/s in the tpruvot ccminer.
Which card is this? and OS.
Skein should do 270 MHASH on the gtx 970 in release 72(cuda 6.5 windows x86)
If you see in the code of the tpruvot branch you will see this:
/* Merged skein512 80 + sha256 64 (in a single kernel) for SM 5+
* based on sp and klaus work, adapted by tpruvot to keep skein2 compat
*/
And this comment:
Merged skeincoin algo for SM5+ devices
Should give same or better than SP and klaus versions
Keep old code for older devices and skein2 compat
Linux perf: 750Ti 78MH/s and GTX 970 260MH/s
Signed-off-by: Tanguy Pruvot
Submitted
luffa512/doom 5% faster. Tiny speedup qubit.
luffa512/doom 5% faster. Tiny speedup qubit.
Thx but is it possible to leave the other 2 cards without the intensity because I don't know what is the default intensity is.
-i 0 should use defaults, so something like "19,0,18" should work
On Nicehash my home rig (51.5 MH) show crazy hashes... 120 MH accepted and 200MH!!!! rejects...
POOL-SIDE PROBLEM? --
Same thing here. The problem just started today, my ccminer updates (dot 72) are several days old. --scryptr
EDIT: Shortly after the last payout, the problem went away. My average paid hash-rate was about the same (and correct) throughout the problem, but the error rate was erroneously high poolside during the problem. My rigs were getting 98% + acceptance reports in the console.
--scryptr
On Nicehash my home rig (51.5 MH) show crazy hashes... 120 MH accepted and 200MH!!!! rejects...
Jump to: