Author

Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1061. (Read 2347601 times)

legendary
Activity: 1400
Merit: 1050
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....
hero member
Activity: 672
Merit: 500
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.
hero member
Activity: 675
Merit: 514
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? ...

Smiley ...

#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 * Cool == 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:
Code:
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 ...
legendary
Activity: 1764
Merit: 1024

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.
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
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? ...

Smiley ...

#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 * Cool == 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 Smiley ...

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 Wink ... 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
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
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? ...

Smiley ...

#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 * Cool == 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 Smiley ...

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

#crysx
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
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? ...

Smiley ...

#crysx
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
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
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
Quote


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.

Smiley true ...

testing the other algos in the next few minutes ...

#crysx
sr. member
Activity: 427
Merit: 250
Quote


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.
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
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://bitcointalksearch.org/topic/a-chainworks-industries-cwi-project-donate-by-mining-dbm-1089744 ...

#crysx
legendary
Activity: 2912
Merit: 1091
--- ChainWorks Industries ---
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
sr. member
Activity: 427
Merit: 250
any of the X algos are less than half as profitable as quark or lyra2re
full member
Activity: 241
Merit: 100
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
legendary
Activity: 1470
Merit: 1114
I don't get some of you guys who are deeming closed source miners being unfair.

Fee doesn't necessarily mean closed source.

For the record I'm not against a fee of some sort but I do prefer open source. The problem with
combining the two is, as wolf0 pointed out, that anyone can code out the fee.


Actually, that's not the actual biggest problem. Most people simply would be too lazy to figure out how to remove it if they don't know already, and some people would even support it.

The real problem with a GPL'd miner is that anyone can edit it out and then redistribute it.

Yikes, even worse distribute with their own fee replacing the dev's. That's really low.
legendary
Activity: 1470
Merit: 1114
I don't get some of you guys who are deeming closed source miners being unfair.

Fee doesn't necessarily mean closed source.

For the record I'm not against a fee of some sort but I do prefer open source. The problem with
combining the two is, as wolf0 pointed out, that anyone can code out the fee.
legendary
Activity: 2002
Merit: 1051
ICO? Not even once.
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.

Devs, miners, pool operators, exchanges, websites they're all for profit.

Sure, I prefer open source but if buying closed source miners is how I could get ahead of others while paying $0.14 kWh then I'm fine with it.
Besides, those open source optimizations will also reach the big farms and at the end of the day cheap electricity,
deep pockets or private kernels really doesn't matter; big farms will always make the most and the small guys will be forced to get out first if things take a turn for the worst (like bitcoin price).


I don't know why a miner fee isn't just used. 1-2% would be perfectly acceptable for all but the scroogest of miners. It keeps the development going and he gets paid for his work. Given how wide spread the miner is, this would be a pretty acceptable amount of income. This has worked for Claymore quite well.

If there is more then one developer working on the miner they can share profits or use whatever model they want to distribute funding. Miners should be seen as a product not a 'donation'. They could even make a company to support this with working developers. Miner fees scale so it's acceptable to everyone mining (except for mega miners, who are reaping most of the profits anyway).

I do agree, there needs to be some background support for the miner developers though to keep them all on the same page and it doesn't turn into the AMD shit show again where everyone gets screwed who doesn't have the money.

Myagui told you: https://bitcointalksearch.org/topic/m.11594243

Fee doesn't necessarily mean closed source. Afaik you can have code that mines for you a few percent as long as you also provide the source code. Sure, in reality most miners would disable it but considering how many people use these miners the profits I believe would still be significant from the rest. Of course there would be some asshats renaming the thing and distributing it with their donation address/pool plugged.


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.
full member
Activity: 139
Merit: 100
SP, the latest commit reports even less hashrate on quark than the previous version. On my 4 750 Tis, it stabilizes around 22650 kH/s when actually mining on a pool, 22620 in benchmark mode. Version 1.5.50 used to report 23040 kH/s which was close to the real value.

The actual hashrate is better on this version, but the reported one seems wrong.
legendary
Activity: 1470
Merit: 1114

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.
legendary
Activity: 1764
Merit: 1024

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.
Jump to: