Epsylon3
Legendary
Offline
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
|
|
November 02, 2015, 08:04:02 PM |
|
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
|
|
|
|
t-nelson
Member
Offline
Activity: 70
Merit: 10
|
|
November 02, 2015, 09:02:02 PM |
|
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
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.
|
BTC: 1K4yxRwZB8DpFfCgeJnFinSqeU23dQFEMu DASH: XcRSCstQpLn8rgEyS6yH4Kcma4PfcGSJxe
|
|
|
joblo
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
November 02, 2015, 10:06:57 PM |
|
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
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?
|
|
|
|
Epsylon3
Legendary
Offline
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
|
|
November 02, 2015, 10:23:36 PM |
|
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
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
November 03, 2015, 06:51:07 AM |
|
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
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..
|
|
|
|
impulse2000
Newbie
Offline
Activity: 26
Merit: 0
|
|
November 03, 2015, 07:54:40 AM |
|
OFF: hashpower and ffpool down again...
|
|
|
|
|
Liquid71
|
|
November 03, 2015, 11:52:51 AM |
|
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
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% 99.9999% 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. Fixed it, you were giving us users too much credit 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
|
|
|
|
Liquid71
|
|
November 03, 2015, 11:59:10 AM |
|
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. 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.
|
|
|
|
Epsylon3
Legendary
Offline
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
|
|
November 03, 2015, 12:01:30 PM |
|
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
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. 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
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
November 03, 2015, 01:00:17 PM |
|
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. 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.
|
|
|
|
Liquid71
|
|
November 03, 2015, 02:31:43 PM |
|
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. 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. Thanks, never even heard of it before but nice price action today gonna switch over to it. 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
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
November 03, 2015, 03:06:45 PM |
|
Thanks I am looking at the Etherum miner now. I have some improvements.
|
|
|
|
theotherme
Member
Offline
Activity: 81
Merit: 10
|
|
November 03, 2015, 03:10:11 PM |
|
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. 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. Thanks, never even heard of it before but nice price action today gonna switch over to it. 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 we don't really care, for your info vtc team is an honest one... (and we all know that when people post that kind of "info", it is because they want to manipulate market)
|
|
|
|
bensam1231
Legendary
Offline
Activity: 1750
Merit: 1024
|
|
November 03, 2015, 04:10:18 PM |
|
I've been mining vert and mbl on p2pool, maybe mbl will take off and add value to the vert mining. 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. There are two exchanges, neither have any amount of volume. No buy support and all sell orders.
|
I buy private Nvidia miners. Send information and/or inquiries to my PM box.
|
|
|
Cryptozillah
|
|
November 03, 2015, 04:17:22 PM |
|
Anyone else having trouble mining lyrarev2 at nicehash right now ? I have "stratum_recv_line_failed" on all my miners right now.
|
|
|
|
Genoil
|
|
November 03, 2015, 04:25:10 PM |
|
Thanks I am looking at the Etherum miner now. I have some improvements. Very curious what you come up with. I hope you can challenge me to look at the code once again, Kind of lost interest with the whole TLB trashing thing going on on Windows.
|
ETH: 0xeb9310b185455f863f526dab3d245809f6854b4d BTC: 1Nu2fMCEBjmnLzqb8qUJpKgq5RoEWFhNcW
|
|
|
joblo
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
November 03, 2015, 04:30:07 PM |
|
Anyone else having trouble mining lyrarev2 at nicehash right now ? I have "stratum_recv_line_failed" on all my miners right now.
No interruptions for me on westhash (lyra2rev2.usa.nicehash.com:3347).
|
|
|
|
Cryptozillah
|
|
November 03, 2015, 04:33:48 PM |
|
Anyone else having trouble mining lyrarev2 at nicehash right now ? I have "stratum_recv_line_failed" on all my miners right now.
No interruptions for me on westhash. The problem seem to be in Europe. I am mining on Amsterdam and it fails. I switched it over to another location and it starts up right away.
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
November 03, 2015, 04:39:42 PM Last edit: November 03, 2015, 05:37:46 PM by sp_ |
|
Thanks I am looking at the Etherum miner now. I have some improvements. Very curious what you come up with. I hope you can challenge me to look at the code once again, Kind of lost interest with the whole TLB trashing thing going on on Windows. in the dagger.cuh: __device__ uint4 fnv4(uint4 a, uint4 b) { uint4 c; c.x = a.x * FNV_PRIME ^ b.x; c.y = a.y * FNV_PRIME ^ b.y; c.z = a.z * FNV_PRIME ^ b.z; c.w = a.w * FNV_PRIME ^ b.w; return c; } Since a.x*2^24= a.x<<24 This can be rewritten to: __device__ uint4 fnv4(uint4 a, uint4 b) { c.x = sharedmemprecalc[a.x&0xff]^ b.x; c.y = sharedmemprecalc[a.y&0xff] ^ b.y; c.z = sharedmemprecalc[a.z&0xff] ^ b.z; c.w = sharedmemprecalc[a.w&0xff] ^ b.w; return c; } The precalcbuffer must be 32bit (256*4 bytes) and the values shifted by 24 bits (shared mem level1cache): xx000000 __shared__ uint32_t sharedmemprecalc[256 * 4]; for (int i = 0; i<256; i++) { sharedmemprecalc[i] = (193 * i) << 24; // Since the FNV_PRIME is a high number the 24 highest bits of the product are ignored. We only need to know the 8 low bits. }
since you ony need to read 1 byte and not the whole 4 bytes (32 bits), you might be able to solve it with 1/4th of the memory reads... __device__ uint4 fnv4(uchar4 a, uint4 b) { c.x = sharedmemprecalc[a.x]^ b.x; c.y = sharedmemprecalc[a.y] ^ b.y; c.z = sharedmemprecalc[a.z] ^ b.z; c.w = sharedmemprecalc[a.w] ^ b.w; return c; } But you might have to reorganize /scramble the memory. and read 32 bit lineary in one read to fill the uchar4.
|
|
|
|
|