|
hashbrown9000
|
 |
June 15, 2015, 03:30:23 AM |
|
any of the X algos are less than half as profitable as quark or lyra2re
|
Pinkcoin:
ETH:
VTC:
BTC:
|
|
|
chrysophylax
Legendary
 Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
June 15, 2015, 03:45:42 AM |
|
I just tried testing version 1.5.52 with the donation settings....
ONLY quark worked. All others were giving 99% reject. I tried the Lyra2 on 2 pools I use (IPO Miner & Verters) and there again 99% reject.
However, when I tried with version 06.15, Lyra2,quark & neoscrypt worked. None of the X series did. Got 99% reject.
Card is EGA GTX 750ti running @ stock
i see that - and the mining on quark continues ... what we seems to find with nicehash is the extranonce2 size issue - and that issue is a regular thing ... for the pool to accept shares - the miner needs to mine for a little bit in order for the nicehash stratums to do what they do ... but again - this seems to be an issue with most of the algos at the moment ... this does not seem to be much of an issue with most other pools - with exception of yaamp on occasion ... GKarB5 - is mining quite nicely of quark at the moment - but the initial 30seconds or so were rejected shares ... https://www.westhash.com/index.jsp?p=miners&a=12&addr=1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd ... im not sure if nicehash force that to happen while the stratum adjusts or it takes longer with more shares with teh other algos ... same happens with yaamp - though not as much for some reason ... all the donation algos are connected to nicehash on the US stratum - except x15 which is completely down on the US stratum altogether ... today ill be testing the other algos over a small period of time with the test miner we have here ... 2 x gigabyte 750ti oc cards ( one card is the lp edition ) and see how they react ... it does seem strange that the previous versions 'worked' on the other algos while the latest didnt for you ... we will be testing with the latest git clone today ... #crysx |
|
|
|
chrysophylax
Legendary
Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
June 15, 2015, 03:53:56 AM |
|
any of the X algos are less than half as profitable as quark or lyra2re
maybe so at the moment - ( and currently you are spot on ) but thats not really what its all about with the donation links ... its about giving some choice of algo to those who wish to mine to donate ... these are obviously test systems currently ... but this testing will help build a more stable system - with a larger variety of algos for choice of mining ... join in and help donate to sp ... the other servers are coming soon - so to give more choice of donation to various devs using various algos ... your ideas and results are most welcome - https://bitcointalk.org/index.php?topic=1089744 ... #crysx |
|
|
|
|
hashbrown9000
|
|
June 15, 2015, 04:31:23 AM |
|
maybe so at the moment - ( and currently you are spot on ) but thats not really what its all about with the donation links ...
well, i was just thinking, mining quark could give SP_ a larger sized beer as opposed to any X algo. |
Pinkcoin:
ETH:
VTC:
BTC:
|
|
|
chrysophylax
Legendary
Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
June 15, 2015, 04:44:56 AM |
|
maybe so at the moment - ( and currently you are spot on ) but thats not really what its all about with the donation links ...
well, i was just thinking, mining quark could give SP_ a larger sized beer as opposed to any X algo.  true ... testing the other algos in the next few minutes ... #crysx |
|
|
|
chrysophylax
Legendary
Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
June 15, 2015, 04:50:49 AM |
|
I just tried testing version 1.5.52 with the donation settings....
ONLY quark worked. All others were giving 99% reject. I tried the Lyra2 on 2 pools I use (IPO Miner & Verters) and there again 99% reject.
However, when I tried with version 06.15, Lyra2,quark & neoscrypt worked. None of the X series did. Got 99% reject.
Card is EGA GTX 750ti running @ stock
i see that - and the mining on quark continues ... what we seems to find with nicehash is the extranonce2 size issue - and that issue is a regular thing ... for the pool to accept shares - the miner needs to mine for a little bit in order for the nicehash stratums to do what they do ... but again - this seems to be an issue with most of the algos at the moment ... this does not seem to be much of an issue with most other pools - with exception of yaamp on occasion ... GKarB5 - is mining quite nicely of quark at the moment - but the initial 30seconds or so were rejected shares ... https://www.westhash.com/index.jsp?p=miners&a=12&addr=1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd ... im not sure if nicehash force that to happen while the stratum adjusts or it takes longer with more shares with teh other algos ... same happens with yaamp - though not as much for some reason ... all the donation algos are connected to nicehash on the US stratum - except x15 which is completely down on the US stratum altogether ... today ill be testing the other algos over a small period of time with the test miner we have here ... 2 x gigabyte 750ti oc cards ( one card is the lp edition ) and see how they react ... it does seem strange that the previous versions 'worked' on the other algos while the latest didnt for you ... we will be testing with the latest git clone today ... #crysx Maybe ccminer is just really fucking sloppy and it assumes extranonce2 size is 4. Would work pretty much everywhere, but sure as hell doesn't conform to the spec. well - you would know better than i wolf ... i work on what info is available and what i can fathom from the what we can see on the stratums off the pool and the internal servers ... its a pity - there doesnt seem to be one standard that all pools and miners conform to ... that standard may exist - but nothing to enforce that all need to conform to it - pools and miners alike ... #crysx |
|
|
|
chrysophylax
Legendary
Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
June 15, 2015, 05:30:37 AM |
|
I just tried testing version 1.5.52 with the donation settings....
ONLY quark worked. All others were giving 99% reject. I tried the Lyra2 on 2 pools I use (IPO Miner & Verters) and there again 99% reject.
However, when I tried with version 06.15, Lyra2,quark & neoscrypt worked. None of the X series did. Got 99% reject.
Card is EGA GTX 750ti running @ stock
i see that - and the mining on quark continues ... what we seems to find with nicehash is the extranonce2 size issue - and that issue is a regular thing ... for the pool to accept shares - the miner needs to mine for a little bit in order for the nicehash stratums to do what they do ... but again - this seems to be an issue with most of the algos at the moment ... this does not seem to be much of an issue with most other pools - with exception of yaamp on occasion ... GKarB5 - is mining quite nicely of quark at the moment - but the initial 30seconds or so were rejected shares ... https://www.westhash.com/index.jsp?p=miners&a=12&addr=1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd ... im not sure if nicehash force that to happen while the stratum adjusts or it takes longer with more shares with teh other algos ... same happens with yaamp - though not as much for some reason ... all the donation algos are connected to nicehash on the US stratum - except x15 which is completely down on the US stratum altogether ... today ill be testing the other algos over a small period of time with the test miner we have here ... 2 x gigabyte 750ti oc cards ( one card is the lp edition ) and see how they react ... it does seem strange that the previous versions 'worked' on the other algos while the latest didnt for you ... we will be testing with the latest git clone today ... #crysx Maybe ccminer is just really fucking sloppy and it assumes extranonce2 size is 4. Would work pretty much everywhere, but sure as hell doesn't conform to the spec. well - you would know better than i wolf ... i work on what info is available and what i can fathom from the what we can see on the stratums off the pool and the internal servers ... its a pity - there doesnt seem to be one standard that all pools and miners conform to ... that standard may exist - but nothing to enforce that all need to conform to it - pools and miners alike ... #crysx I really, really agree; while we're at it, can we make a GBT-Stratum hybrid? Would be awesome - miners could even include their own tx in a block they mine for the pool. Plus, miners can check to see if the pool is doing something evil like a 51% and scream bloody murder - simply check every now and again if prevhash actually was the hash of the previous block. hehehe ... got a design in mind? ... i can have the infrastructure ready and you can do the development ... can i safely assume that the miner you are designing will work seamlessly with ALL stratums? ... ... #crysx |
|
|
|
chrysophylax
Legendary
Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
June 15, 2015, 06:31:05 AM |
|
I just tried testing version 1.5.52 with the donation settings....
ONLY quark worked. All others were giving 99% reject. I tried the Lyra2 on 2 pools I use (IPO Miner & Verters) and there again 99% reject.
However, when I tried with version 06.15, Lyra2,quark & neoscrypt worked. None of the X series did. Got 99% reject.
Card is EGA GTX 750ti running @ stock
i see that - and the mining on quark continues ... what we seems to find with nicehash is the extranonce2 size issue - and that issue is a regular thing ... for the pool to accept shares - the miner needs to mine for a little bit in order for the nicehash stratums to do what they do ... but again - this seems to be an issue with most of the algos at the moment ... this does not seem to be much of an issue with most other pools - with exception of yaamp on occasion ... GKarB5 - is mining quite nicely of quark at the moment - but the initial 30seconds or so were rejected shares ... https://www.westhash.com/index.jsp?p=miners&a=12&addr=1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd ... im not sure if nicehash force that to happen while the stratum adjusts or it takes longer with more shares with teh other algos ... same happens with yaamp - though not as much for some reason ... all the donation algos are connected to nicehash on the US stratum - except x15 which is completely down on the US stratum altogether ... today ill be testing the other algos over a small period of time with the test miner we have here ... 2 x gigabyte 750ti oc cards ( one card is the lp edition ) and see how they react ... it does seem strange that the previous versions 'worked' on the other algos while the latest didnt for you ... we will be testing with the latest git clone today ... #crysx Maybe ccminer is just really fucking sloppy and it assumes extranonce2 size is 4. Would work pretty much everywhere, but sure as hell doesn't conform to the spec. well - you would know better than i wolf ... i work on what info is available and what i can fathom from the what we can see on the stratums off the pool and the internal servers ... its a pity - there doesnt seem to be one standard that all pools and miners conform to ... that standard may exist - but nothing to enforce that all need to conform to it - pools and miners alike ... #crysx I really, really agree; while we're at it, can we make a GBT-Stratum hybrid? Would be awesome - miners could even include their own tx in a block they mine for the pool. Plus, miners can check to see if the pool is doing something evil like a 51% and scream bloody murder - simply check every now and again if prevhash actually was the hash of the previous block. hehehe ... got a design in mind? ... i can have the infrastructure ready and you can do the development ... can i safely assume that the miner you are designing will work seamlessly with ALL stratums? ... ... #crysx All that follow the damned specification. If they send me an odd extranonce like 3 or 7, I'll use up to that size, and return to them that many bytes. Incrementing it like it should be is kind of a bitch, though... actually, now that I think about it, just mask off the rest with 256 shifted up by 8 * the number of bytes minus one. If the counter can be only 3 bytes or some odd shit like that, 0x100 << (3 *  == 0x1000000, subtract one and you have a perfect mask - 0xFFFFFF. Wonder why the reference implementation (the python Slush did) did it so... verbosely. funnily enough - all the proxies we used to use were slushes ... the stratum proxies that are currently being implemented are all stratehm stratum proxies ... java based - and easier to implement - and seem to have less issues than slushes ... but unfortunately seem to chew more memory ( RAM ) which is why only a few can be implemented at once ... as for the formulations - thats all yours mate  ... hehehe ... #crysx |
|
|
|
chrysophylax
Legendary
Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
June 15, 2015, 06:44:58 AM |
|
I just tried testing version 1.5.52 with the donation settings....
ONLY quark worked. All others were giving 99% reject. I tried the Lyra2 on 2 pools I use (IPO Miner & Verters) and there again 99% reject.
However, when I tried with version 06.15, Lyra2,quark & neoscrypt worked. None of the X series did. Got 99% reject.
Card is EGA GTX 750ti running @ stock
i see that - and the mining on quark continues ... what we seems to find with nicehash is the extranonce2 size issue - and that issue is a regular thing ... for the pool to accept shares - the miner needs to mine for a little bit in order for the nicehash stratums to do what they do ... but again - this seems to be an issue with most of the algos at the moment ... this does not seem to be much of an issue with most other pools - with exception of yaamp on occasion ... GKarB5 - is mining quite nicely of quark at the moment - but the initial 30seconds or so were rejected shares ... https://www.westhash.com/index.jsp?p=miners&a=12&addr=1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd ... im not sure if nicehash force that to happen while the stratum adjusts or it takes longer with more shares with teh other algos ... same happens with yaamp - though not as much for some reason ... all the donation algos are connected to nicehash on the US stratum - except x15 which is completely down on the US stratum altogether ... today ill be testing the other algos over a small period of time with the test miner we have here ... 2 x gigabyte 750ti oc cards ( one card is the lp edition ) and see how they react ... it does seem strange that the previous versions 'worked' on the other algos while the latest didnt for you ... we will be testing with the latest git clone today ... #crysx Maybe ccminer is just really fucking sloppy and it assumes extranonce2 size is 4. Would work pretty much everywhere, but sure as hell doesn't conform to the spec. well - you would know better than i wolf ... i work on what info is available and what i can fathom from the what we can see on the stratums off the pool and the internal servers ... its a pity - there doesnt seem to be one standard that all pools and miners conform to ... that standard may exist - but nothing to enforce that all need to conform to it - pools and miners alike ... #crysx I really, really agree; while we're at it, can we make a GBT-Stratum hybrid? Would be awesome - miners could even include their own tx in a block they mine for the pool. Plus, miners can check to see if the pool is doing something evil like a 51% and scream bloody murder - simply check every now and again if prevhash actually was the hash of the previous block. hehehe ... got a design in mind? ... i can have the infrastructure ready and you can do the development ... can i safely assume that the miner you are designing will work seamlessly with ALL stratums? ... ... #crysx All that follow the damned specification. If they send me an odd extranonce like 3 or 7, I'll use up to that size, and return to them that many bytes. Incrementing it like it should be is kind of a bitch, though... actually, now that I think about it, just mask off the rest with 256 shifted up by 8 * the number of bytes minus one. If the counter can be only 3 bytes or some odd shit like that, 0x100 << (3 * == 0x1000000, subtract one and you have a perfect mask - 0xFFFFFF. Wonder why the reference implementation (the python Slush did) did it so... verbosely. funnily enough - all the proxies we used to use were slushes ... the stratum proxies that are currently being implemented are all stratehm stratum proxies ... java based - and easier to implement - and seem to have less issues than slushes ... but unfortunately seem to chew more memory ( RAM ) which is why only a few can be implemented at once ... as for the formulations - thats all yours mate ... hehehe ... #crysx Why do people use languages that are terribly suited to this? Python and Java are both easy to use, but interpreted, and therefore there's gonna be SOME performance hit. If your miners aren't using getwork, the proxy doesn't need to save anything for each miner, so what the fuck are they using a lot of RAM for? Which are the miners using, getwork or Stratum? stratum ... about 250MB per proxy - which fluctuates ... #crysx |
|
|
|
bensam1231
Legendary
Offline
Activity: 1750
Merit: 1024
|
|
June 15, 2015, 06:57:17 AM |
|
An alternative funding scheme I would like to propose is that coin devs get more involved
in funding open source development.
They are already doing it, that's how you got: lyra2re, coinshield, yescrypt (Yglobalboost), pluck, ziftr,creditcurrency and others True, a coin that is first to use an algorithm needs to have a functioning miner but the coin devs don't seem very interested in optimized miners. Their fear of ASICs, and to a lesser extent GPUs means they choose algos that are particularly difficult to optimize, which in turn means only the most talented coders can implement those optimizations. I'm not suggesting coin devs lead the charge to ASICS but they should try to keep open source miners at optimum to discourage the development of private kernels and ASICs which tilt the playing field. That's funny in and of itself because a optimized miner is essentially the equivalent of what ASICs brought to market for sha256 and then scrypt. It makes all other tech irrelevant when it starts spreading. Initially it doesn't make a big impact, but with enough bulk it pushes everything else down. It's the same thing. Not quite. Everyone has a CPU, many have a GPU, few have an ASIC miner. As you go up the ladder you shrink the user base. Optimizing the lower end slows that arms race. Whether it can stop it can be argued but 1 1/2 years later there is still no x11 ASIC AFAIK. When those optimizations are reserved for the select few, the miners become the ASICs. It obsoletes hardware for people who don't have them just as fast. I don't think miners or optimizing miners will ever stop ASICs. If no one improved miners the world would actually be in a better place as we'd all be on the same playing field, with the exception of improvements in efficiency, as power is a baseline cost. But there is always someone that wants to sell a miner so there is a constant arms race in miners now (just the same as ASICs), which is why we need a support structure for miner developers so we don't run into assholes ruining things for everyone else. If it's ever worth making a ASIC or maybe a FPGA, optimized miners will be piss in the bucket as far as that's concerned. They can't stop them if someone wants to make hardware designed specifically for the task. Just the same as GPUs being better at mining then CPUs (relatively speaking). The more specific the hardware, the less difference software can make. I don't get some of you guys who are deeming closed source miners being unfair. By that logic cheap electricity or owning more than average amount of mining hardware could also be considered unfair.
If anything, expecting devs to work for the occasional few beers donation for their work especially when hundreds if not thousands of people are using their work is unfair.
Just to stipulate again a closed miner doesn't mean it needs to be a paid miner. Closed source can be free. The problem arises when the miners are so inherently expensive and sold in such a way that no one knows they exist or how to find them, it screws everyone else. Miner developers talking about this right now throw around words like 'capitalism' and such, but they don't even have a market place so the 'free market' cant even have one of the most fundamental parts of it, competition. This is especially problematic when the miners are sold to people with the most hash rate and of course they're also the ones that can afford it as such. Since mining is a pie distribution, this pushes everyone else down so people with higher hash can make more money. Someone mining with a 970 with a open source kernel may not even be profitable anymore. Look at the opensource miners for AMD, none of them are profitable anymore (depending on power costs). Given AMD sucks at efficiency, this is an example of how private paid miners for the elite few completely fuck things up. If you look at YAMP, there are still a lot of sgminers on there. Since we can't get rid of private miners, it's about making it accessible by everyone, so a few people don't completely rape everyone else. A dev fee does this quite well and can even be used to fund a company to keep this up and end this western stylized miner gun show. This is also why some miner devs are bitching so much about what I'm saying. Actually nailing this down and making infrastructure will stop some of them from reaping the most rewards from what's currently happening, which is freelance development for the elite few. That's funny in and of itself because a optimized miner is essentially the equivalent of what ASICs brought to market for sha256 and then scrypt. It makes all other tech irrelevant when it starts spreading. Initially it doesn't make a big impact, but with enough bulk it pushes everything else down. It's the same thing.
Except in this case optimized miners are free while ASICs are certainly not. If ASICs would become free the next day they'd turn into useless junk. I didn't know Wolf0 and DJMs miners were free. Even SP has a paid miner, although for select kernels. This is starting to turn into a IP argument and while I agree there should be a paid model here, it's important to note there is a different amount of funding that goes into developing a ASIC compared to a random guy that knows how to program in OCL. Arguably if the same amount of funding went into developing miners as ASICs you'd end up with a product almost no solo developer could touch as the amount of time sink would be ridiculous, unless they too start a company and higher talent. We currently have a problem with solo miner devs due to no competition and no market so anything is basically better then what's available, especially since the software everyone uses (like SP miner) is open. Since talent can be split among different algos as well, a company could design a single miner for basically every algo and then improve on it. There is a LOT of hash that goes through the market. Since everyone would be using the miner, a fee would make them fuck tons of money, be fair for everyone, and also offer proofing against gunslinging solo devs looking to make a quick buck. As far as coding out a fee... This only happens because developers don't spend enough time making the application and all they do is make a slightly modified version of spminer/ccminer/cgminer. This is a DRM issue and could be taken care of with talent as well. There is nothing stopping people from making a more robust application that requires activation or would offer more protection to the user. It's a BS excuse to perpetuate solo get rich fast development. If people are going to donate or 'pay' for a miner, we can assume they'd also do a miner fee. There are always people that will try not to pay and if something is too expensive for what it's worth, one could argue rightfully so. Some miners have popped up with something like a 15% miner fee and at that point it's good they get lobotomized. It's pretty easy to get pirated software. Not everyone pirates though. Not everyone is going to use a pirated miner even if it's available. Of course a updated product cycle and a more robust program would also push this down. I know, I'm talking about actual work and turning what developers are selling into a reputable product. |
I buy private Nvidia miners. Send information and/or inquiries to my PM box.
|
|
|
|
Schleicher
|
|
June 15, 2015, 07:11:58 AM |
|
I just tried testing version 1.5.52 with the donation settings....
ONLY quark worked. All others were giving 99% reject. I tried the Lyra2 on 2 pools I use (IPO Miner & Verters) and there again 99% reject.
However, when I tried with version 06.15, Lyra2,quark & neoscrypt worked. None of the X series did. Got 99% reject.
Card is EGA GTX 750ti running @ stock
i see that - and the mining on quark continues ... what we seems to find with nicehash is the extranonce2 size issue - and that issue is a regular thing ... for the pool to accept shares - the miner needs to mine for a little bit in order for the nicehash stratums to do what they do ... but again - this seems to be an issue with most of the algos at the moment ... this does not seem to be much of an issue with most other pools - with exception of yaamp on occasion ... GKarB5 - is mining quite nicely of quark at the moment - but the initial 30seconds or so were rejected shares ... https://www.westhash.com/index.jsp?p=miners&a=12&addr=1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd ... im not sure if nicehash force that to happen while the stratum adjusts or it takes longer with more shares with teh other algos ... same happens with yaamp - though not as much for some reason ... all the donation algos are connected to nicehash on the US stratum - except x15 which is completely down on the US stratum altogether ... today ill be testing the other algos over a small period of time with the test miner we have here ... 2 x gigabyte 750ti oc cards ( one card is the lp edition ) and see how they react ... it does seem strange that the previous versions 'worked' on the other algos while the latest didnt for you ... we will be testing with the latest git clone today ... #crysx Maybe ccminer is just really fucking sloppy and it assumes extranonce2 size is 4. Would work pretty much everywhere, but sure as hell doesn't conform to the spec. well - you would know better than i wolf ... i work on what info is available and what i can fathom from the what we can see on the stratums off the pool and the internal servers ... its a pity - there doesnt seem to be one standard that all pools and miners conform to ... that standard may exist - but nothing to enforce that all need to conform to it - pools and miners alike ... #crysx I really, really agree; while we're at it, can we make a GBT-Stratum hybrid? Would be awesome - miners could even include their own tx in a block they mine for the pool. Plus, miners can check to see if the pool is doing something evil like a 51% and scream bloody murder - simply check every now and again if prevhash actually was the hash of the previous block. hehehe ... got a design in mind? ... i can have the infrastructure ready and you can do the development ... can i safely assume that the miner you are designing will work seamlessly with ALL stratums? ... ... #crysx All that follow the damned specification. If they send me an odd extranonce like 3 or 7, I'll use up to that size, and return to them that many bytes. Incrementing it like it should be is kind of a bitch, though... actually, now that I think about it, just mask off the rest with 256 shifted up by 8 * the number of bytes minus one. If the counter can be only 3 bytes or some odd shit like that, 0x100 << (3 * == 0x1000000, subtract one and you have a perfect mask - 0xFFFFFF. Wonder why the reference implementation (the python Slush did) did it so... verbosely. ccminer is using this code to check the size: if(xn2_size < 2 || xn2_size > 16)
{
applog(LOG_ERR, "invalid n2size in parse_extranonce: size=%d", xn2_size);
goto out;
}
And then sometimes the pool wants a size of 1 ... |
|
|
|
|
MaxDZ8
|
|
June 15, 2015, 09:56:11 AM |
|
Just two things to point out: - GPUs are basically better at everything (not just mining) they are a proper compute-oriented architecture, vector processing as it always have been. The "CPU for compute" mindset is borderline Intel propaganda. HPC switched to GPUs years ago and the only points where CPUs are competitive is when shit is written on purpose.
- AMD does not suck at efficiency. My 7750 hashes half as fast as a 750Ti, it also costed me half as much, a few months before the 750Ti launched...
- BUT! Maxwell consumes half as much! Maybe. I estimate room for 150% in hashrate with perhaps a 10% power increase. I consider Maxwell a good chip but not to the point to make GCN obsolete; leaving aside there's no low-end Maxwell yet.
You guys keep talking about efficiency but it's obvious to me you should talk efficiency of the algorithm implementations instead of drawing a connection to the hardware. That's fairly obvious considering how much talk about ah-hoc kernels around here. |
|
|
|
|
djm34
Legendary
Offline
Activity: 1400
Merit: 1050
|
|
June 15, 2015, 10:55:27 AM |
|
Just two things to point out: - GPUs are basically better at everything (not just mining) they are a proper compute-oriented architecture, vector processing as it always have been. The "CPU for compute" mindset is borderline Intel propaganda. HPC switched to GPUs years ago and the only points where CPUs are competitive is when shit is written on purpose.
- AMD does not suck at efficiency. My 7750 hashes half as fast as a 750Ti, it also costed me half as much, a few months before the 750Ti launched...
- BUT! Maxwell consumes half as much! Maybe. I estimate room for 150% in hashrate with perhaps a 10% power increase. I consider Maxwell a good chip but not to the point to make GCN obsolete; leaving aside there's no low-end Maxwell yet.
You guys keep talking about efficiency but it's obvious to me you should talk efficiency of the algorithm implementations instead of drawing a connection to the hardware. That's fairly obvious considering how much talk about ah-hoc kernels around here. You're talking to a place full of rabid Nvidia fans - I've pointed out reality, and that's that Maxwell actually isn't as great with efficiency as 50%. Sure, when AMD is running a lobotomized implementation, while CUDA is popular and fairly well done, it looks to be so efficent there's just no point in mining with AMD. But I ran my X11 on a 270X and benched it against a 750TI back when I had around 5 of them - this was before sp_'s work - and I got a difference of around 5% in efficiency between the two - 270X was OC'd, 750Ti the same, TDP raised on the 750TI. Now, consider it heresay, since I don't have a record that far back, nor do I have the card anymore (and the exact ccminer version), but even taking into account that the 270X and 750Ti could be undervolted, and that sp_ has made a LOT of improvements... it still doesn't scream huge, insurmountable difference. will see what the stacked memory will bring, might be the only reason for me to buy an amd.... |
djm34 facebook pageBTC: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze Pledge for neoscrypt ccminer to that address: 16UoC4DmTz2pvhFvcfTQrzkPTrXkWijzXw
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
June 15, 2015, 11:22:06 AM |
|
I rewrote cubehash and saved some registers. Look's like x11 is +5khash on the 750ti, so practically no gain...  but no more insane tables like this one: x[0][0][0][0][0] ^= in[0]; |
|
|
|
|
Angora
|
|
June 15, 2015, 12:41:59 PM |
|
I just tried testing version 1.5.52 with the donation settings....
ONLY quark worked. All others were giving 99% reject. I tried the Lyra2 on 2 pools I use (IPO Miner & Verters) and there again 99% reject.
However, when I tried with version 06.15, Lyra2,quark & neoscrypt worked. None of the X series did. Got 99% reject.
Card is EGA GTX 750ti running @ stock
i see that - and the mining on quark continues ... what we seems to find with nicehash is the extranonce2 size issue - and that issue is a regular thing ... for the pool to accept shares - the miner needs to mine for a little bit in order for the nicehash stratums to do what they do ... but again - this seems to be an issue with most of the algos at the moment ... this does not seem to be much of an issue with most other pools - with exception of yaamp on occasion ... GKarB5 - is mining quite nicely of quark at the moment - but the initial 30seconds or so were rejected shares ... https://www.westhash.com/index.jsp?p=miners&a=12&addr=1CTiNJyoUmbdMRACtteRWXhGqtSETYd6Vd ... im not sure if nicehash force that to happen while the stratum adjusts or it takes longer with more shares with teh other algos ... same happens with yaamp - though not as much for some reason ... all the donation algos are connected to nicehash on the US stratum - except x15 which is completely down on the US stratum altogether ... today ill be testing the other algos over a small period of time with the test miner we have here ... 2 x gigabyte 750ti oc cards ( one card is the lp edition ) and see how they react ... it does seem strange that the previous versions 'worked' on the other algos while the latest didnt for you ... we will be testing with the latest git clone today ... #crysx The error I get from new version is "share above target". I ran quark on suprnova for 6 hrs and error rate was just under 5%. Was getting some nice hash rates. About 1 minute out of gate, 1.2M on the pool. Does it make a difference as to which version of Cuda is installed? I have v7 installed. OS win8.1 64bit |
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
June 15, 2015, 02:01:26 PM |
|
If you build it yourself you need cuda 6.5. This fork has issues with cuda 7.
|
|
|
|
rednoW
Legendary
Offline
Activity: 1510
Merit: 1003
|
|
June 15, 2015, 04:36:27 PM |
|
2 sp_
Some testing your own built #52 vs. fresh github clone (my own build) vs one of the best "old" #47
gtx 750 best results
x11 2958 vs 2964 vs 2950
lyra2re 912 vs 909 vs 904
quark 6000 vs 5965 vs 5980
neoscrypt 190 vs 190 vs n/a
Please, return back quark and lyra performance for compute 5.0 ))
|
|
|
|
|
bensam1231
Legendary
Offline
Activity: 1750
Merit: 1024
|
|
June 15, 2015, 04:57:41 PM |
|
Bugreport for Neoscrypt. Running 5 970s on the same system causes it to spit out "Cuda error in func 'scanhash-neoscrypt' at line 67 : out of memory."
Limiting it to any 4 devices with -d eliminates the problem. Tried running separate instances with different devices, doesn't work. System memory is fine. DJM's miner has the same problem.
|
I buy private Nvidia miners. Send information and/or inquiries to my PM box.
|
|
|
rednoW
Legendary
Offline
Activity: 1510
Merit: 1003
|
|
June 15, 2015, 06:03:43 PM |
|
Bugreport for Neoscrypt. Running 5 970s on the same system causes it to spit out "Cuda error in func 'scanhash-neoscrypt' at line 67 : out of memory."
Limiting it to any 4 devices with -d eliminates the problem. Tried running separate instances with different devices, doesn't work. System memory is fine. DJM's miner has the same problem.
try to use -i param with lower intensity, e.g. 14.3 |
|
|
|
|
djm34
Legendary
Offline
Activity: 1400
Merit: 1050
|
|
June 15, 2015, 07:28:37 PM |
|
Bugreport for Neoscrypt. Running 5 970s on the same system causes it to spit out "Cuda error in func 'scanhash-neoscrypt' at line 67 : out of memory."
Limiting it to any 4 devices with -d eliminates the problem. Tried running separate instances with different devices, doesn't work. System memory is fine. DJM's miner has the same problem.
you need more memory... or pagefile... (which is required to allocate that memory to the gpu...) alternatively you can lower the intensity, that should free up some memory other alternative, try to start 1 or 2 ccminer session |
djm34 facebook pageBTC: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze Pledge for neoscrypt ccminer to that address: 16UoC4DmTz2pvhFvcfTQrzkPTrXkWijzXw
|
|
|
|
